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I.  EACKGBCM3SP  AMD  OYBBYIBW 


1.  1HOTEES  DECISIOH  1ID  !?  —  1  DBFBBSE 

. . .  I  never  needed  any  computer  to  make  a  decision  for 

ae  .  our  success  just  gees  to  show  you  don't  need 

any  of  these  fancy  computer  systems  when  it  cones  right 
down  tc  trass  tacks... 

Six  months  into  development  of  a  thesis  which  was 
designing  a  computer  based  Decision  Support  System,  this 
statement  is  somewhat  provocative.  Recently,  this  author 
sat  in  an  audience  captivated  by  the  dynamic  commander  who 
was  on  stage.  A  portion  of  his  closing  remarks  included 
the  paraphrase  which  headed  this  chapter.  Mas  the  connota¬ 
tion  of  his  statement  more  than  his  egc-involvement  spawned 
by  the  euphoric  taste  of  success? 

The  mandate  of  command  is  to  make  decisions  when  opera¬ 
tions  "come  down  tc  brass  tacks."  There  is  no  such 
mandate  for  a  computer  system.  The  commander  who  doesn't 
avail  himself  of  all  sources  and  methods  of  display  of 
information  cannot  be  as  confident  of  his  decisions  as  the 
commander  who  does.  The  complexity  of  contemporary  peace¬ 
time  and  wartime  operations,  in  concert  with  technological 
advancements  which  are  cccuring  at  near  exponential  rates, 
is  eften  times  characterized  by  too  much  information  to 
digest,  hewever.  Computer  supported  decision  making  can 
overwhelm  and  often  dilute  human  capabilities  by  prolifer¬ 
ating  the  volumes  of  knowledges  which  a  user  feels  compelled 
to  assimilate.  This  gives  rise  to  a  common  malady  in  the 
Hilitary,  "decision  aid  angst." 

Originally,  computer  systems  focussed  on  abilities  to 
manage  massive  ameunts  of  information,  a  Management 


Inf  citation  System  (CIS).  (Sore  recently,  the  focus  has 
shifted  to  translating  existing  technological  capabilities 
into  Decision  Support  Systems  (DSS)  .  The  DSS  channels  the 
■assies  data  processing  capabilities  of  today's  computer 
technology  towards  the  "decision"  and  away  from  demon¬ 
strating  how  much  data  can  be  manipulated.  DSS,  in  the 
purists'  view,  is  an  extension  of  the  innervorkings  of  the 
commander  himself.  The  commander  has  participated  in  its 
design,  and  it  then  allows  him  to  make  a  comprehensive  deci¬ 
sion  based  cn  information  organized  for  presentation  in  a 
format  be  desires.  Bow  the  designer  of-  the  DSS  defines  the 
user-system  interaction  requirements  as  well  as  the  format 
of  the  information  display,  becomes  the  difference  between 
whether  the  power  to  the  system  is  "on"  throughout  the  deci¬ 
sion  making  process,  cr  "off,"  archieved  for  "future  use." 

This  thesis  addresses  an  interactive  decision  support 
system  for  a  battle  group  commander,  to  enhance  the  effec¬ 
tive  management  of  the  assets  assigned  to  the  battle  group. 
It  focusses  on  a  realistic  dialogue  [Bef.  1]  and  substantive 
information  representation  to  expand  its  useability  and  not 
dust  collecting  capability. 

B.  D1CISICI  SUPPORT  STSTEHS 

Icr  a  Decision  support  System  to  have  long-term  utility, 
it  must  be  the  result  of  an  "evolutionary  "  design  process. 
This  process  must  address  both  the  evolution  of  the  tech¬ 
nology,  and  that  of  the  user. 

The  necessary  iterative  design  process  relies  on  short¬ 
term  feedback  between  the  user  and  the  developer  tc  ensure 
that  requirad  change  is  implemented  in  the  short  term. 
This  process  applies  to  the  three  fundamental  subsystems  of 
a  DSS,  dialogue,  data  management,  and  model  management. 
[Bef.  1] 
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This  thesis  addresses  a  specific  component  of  a  battle 
group  commander's  sphere  of  responsibility,  asset  manage¬ 
ment.  It  has  been  developed  based  on  this  author's  experi¬ 
ence  in  Fleet  operations.1  As  the  designer  and  user  of  the 
ESS,  the  precepts  discussed  above,  fundamental  to  the  design 
cf  a  ESS,  have  been  met.  Extension  of  the  applicability  to 
follow-on  user  groups  would  necessitate  "evolutionary"  fine 
tuning  tc  each  group.  This  DSS  is  based  on  a  schema  of 
management  of  a  capabilities  database  of  a  designed  battle 
group,  and  translating  that  database  into  descriptive 
computer  graphics  displays.  Control  of  DSS  operations 
with  respect  to  user-system  interaction  represents  state  of 
the  art  technology  in  the  utilization  of  voice  recognition 
protccols.  Kith  the  use  of  voice,  the  user  is  thus  free 
from  the  confines  of  a  terminal  keyboard.  The  system,  as 
developed,  does  not  represent  a  stand  alone  DSS  in  the 
complete  sense  discussed  above.  The  "Model  Subsystem" 
[Hef.  1  ]  is  manifested  in  the  tactical  knowledges  of  the 
user,  and  not  an  analytic  or  mathematical  model. 
Incor pcraticn  of  such  a  model  or  models  is  an  obvious 
follow-or  enhancement  to  the  system.  Less  a  model 
subsystem,  a  semantic  title  of  "Decision  support  Subsystem" 
may  be  contemplated,  however,  in  actuality,  this  system  does 
operate  based  on  a  acdel,  the  user.  The  "model"  which  this 
CSS  utilizes,  resides  in  the  mind,  experience,  and  fibr6  of 
a  user,  which  has  been  hcned  throughout  a  career.  The 
cutgrcwth  cf  this  system  is  an  extension  of  the  commander's 
"mind's  eye,"  an  interface  between  the  conceptual  and  the 
real.  In  formulating  the  best  employment  of  his  battle 
group,  based  on  the  capability  (sensor  and  weapons)  of  each 


,  *lhe  author  has  participated  m  6  HEADJEX,  3  FLEETEX, 
and  numerous  other  warfare  exercisas.  This  experience  has 
included  functioning  as  a  principle  watchstander  for  the 
ASHC,  ASOfiC,  or  AAHC  in  the  majority  of  those  operations. 
Additionally,  the  author  har  -* 

lactical  Training  Course. 


is  attended  the  TACTRAGHOPAC  Staff 
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ship  is  the  force,  this  DSS  allows  the  commander  to  exter¬ 
nally  visualize  the  interplay  of  capabilities  among  these 
assets. 

C.  DIALOGUE  SUBSYSTEM  DEYELOIBE1T 

Any  systes  which  encoapass es  a  aan-aachine  interaction 
must  strive  for  that  illusive  "symbiotic"  relationship  where 
■an  and  aachine  are  in  haraonic  unison  with  each  ether. 
The  principle  stuabling  block  to  achievement  of  this  goal 
has  been  the  format  of  the  language  which  joins  the  two, 
English  versus  "Computerese."  Additionally,  the  "angst" 
mentioned  earlier  can  be  an  outgrowth  of  a  deficiency  of 
clerical  skills  on  the  part  of  the  user,  at  the  interface. 
The  challenge  is  accentuated  by  the  speed  mismatches  between 
tan  and  aachine  "thinking. "  The  issue  is  to  construct  a 
common  language  at  the  interface,  where  the  goals  and  inten¬ 
tions  of  the  user  are  easily  translated  into  the  logical 
courses  cf  action  of  the  computer.  t8«f»  2] 

Can  a  computer  really  be  friendly?  This  guestion 
should  acre  accurately  replace  "computer"  with  "computer 
software  designer."  Therein  lies  the  source  of  many  of 
today's  misgivings.  The  software  designer  must  be  attuned 

to  the  real  world  requirements  and  not  just  code  formats  or 
primitives.  If  the  designer  looks  at  the  man-machine  envi¬ 
ronment,  and  accurately  interprets  it,  then  computers  can 
indeed  be  "friendly."  Users,  by  their  human  nature,  have 
expectations.  Therefore,  a  computer  system  should  be 
predictable.  The  adversarial  relationship  which  could 
develop  between  man  and  machine  is  eliminated  when  the  user 
is  given  responses  from  the  system  which  reinforce  a  confi¬ 
dence  that  the  information  is  "shared,"  and  not  one  sided. 
This  relationship  is  further  cultivated  by  the  system 
returning  positive  feedback  to  the  user  when  a  response  is 
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entered,  a  stop-gap  fcr  potential  anxi9ty.  When  all  these 
concepts  are  merged,  the  key  which  unlocks  the  puzzle  points 
to  "vocabulary. "  [ Bef.  3] 

This  DSS  has  taken  into  account  the  vernacular  of  the 
battle  group  and  interfaced  it  with  the  vocabulary  of  the 
computer.  Going  one  step  further,  the  input  medium,  with 
voice  recognition,  has  allowed  th9  evolution  of  the  inputs 
intc  a  conversational  and  not  cpmman^  format.  Flexibility 
has  been  incorporated  into  the  formats  by  allowing  multiple 
options  fcr  each  component  of  a  conversational  construct. 
Therefore,  consistency  is  met  while  concurrently  allowing 
flexibility  to  meet  the  user's  multiple  needs.  Internal  to 
the  system,  this  practice  moves  one  step  further  with 
commonly  used  conversational  inputs  grouped  into  single  wcrd 
inputs,  when  feasible. 

Finally,  the  value  of  operating  the  system  through  voice 
control  cannot  be  overstated.  Mot  only  does  this  interac¬ 
tive  format  free  the  user  from  translation  of  his  thought 
processes  through  a  keyboard,  but  also  provides  mobility 
throughout  the  work  center  or  watch  station,  while  main¬ 
taining  control  of  the  system.  The  pragmatics  of  the 
conveisaticnal  interactions  in  this  DSS,  while  accomodating 
multiple  options,  nearly  exhausts  the  256  utterance  vocabu¬ 
lary  of  this  discrete  speech  equipment  (Threshold 
Technology's  T-600).  However,  while  the  obvious  extension 
is  to  convert  the  DSS  to  a  connected  speech  technology,  when 
properly  trained,  the  T-600  has  shown  remarkable  ability  to 
discriminate  utterances  and  handle  the  demand. 

E.  BZSICH  PHILO  SOP  HI 

There  were  three  principle  design  philosophies  which  the 
author  adhered  to  in  developing  this  DSS.  First,  the 
system  is  suyvivable.  or  in  another  parlance,  "robust. " 


The  query/response  sequences  are  all  supported  by  system 
error  checks  to  preclude  unintentional  "bombing"  of  the 
system,  and  reduce  user  apprehension.  Each  view  which 
requires  a  user  response  shows  exaaples  of  correct 
responses.  The  differences  between  the  entry  formats  for 

keyboard  and  voice  are  illustrated,  in  detail,  in  the  User's 
Manual,  the  third  chapter  of  this  thesis.  In  addition  to 
providing  as  error  check  of  the  inputs,  the  language  is 
simple  and  replicates  how  the  user  would  normally  articulate 
the  parameter  being  addressed.  Additionally,  the  Osar's 
Manual  shows  example  sequences  through  a  complete  session 
with  the  system,  reproducing  the  logical  inputs  and  system 
responses,  as  well  as  errcr  recovery  features.  Finally, 
the  DSS  is  consistent.  in  that  the  types  of  entries  and 
their  respective  results  are  identical  throughout  the  eight 
modules  cf  the  system. 

I.  6BAPBICS  —  IHPBCVIIG  PEBCEPTIOH  OP  CAPABILITIES 

The  "acid  test"  of  the  performance  of  any  sensor  or 
weapons  system  is  in  actual  operations.  When  these  opera¬ 
tions  are  with  an  adversary,  whether  in  an  exercise  or  real 
world,  the  preparatory  thought  given  to  rhe  employment  of 
those  assets  significantly  impacts  on  their  aggregate 
performance.  In  assimilating  the  huge  amounts  of  data 
required  to  make  a  credible  decision  as  to  asset  employment, 
timeliness  requires  the  commander  digest  that  information  in 
"chunks."  The  results  of  numerous  studies  have  borne  cut 
that  visual  perception  of  large  amounrs  cf  information 
significantly  increases  human  ability  to  draw  inferences  and 
make  subsequent  judgements.  The  same  graphics  display  may 
represent  differing  interpretations  to  different  people. 
However,  the  "evolutionary"  design  process  of  a  DSS, 
precludes  this  eventuality  by  having  had  the  commander 


provide  the  inpat  as  to  the  design  of  the  displays,  and 
thereby  the  format  of  the  information  represented.  [Bef.  4] 

The  graphics  capabilities  of  this  DSS  reflect  state  of 
the  art  graphics  technology.  Ihe  applications  progzaas  for 
the  displays  are  written  utilizing  the  DI-3000  software 
language.  The  only  shortfall  of  the  hardware  in  use  is 
that  it  dees  not  allow  coaplete  filling  of  overlapping  poly¬ 
gons  (principally  circles  in  this  case)  on  the  sane  view. 
This  reduces  the  effectiveness  of  the  overall  sensor/weapons 
coverage  displays  by  having  multiple  circles  shown  vice  one 
solid  area  for  force  coverage.  The  bottom  line,  though,  is 
that  the  graphics  displays,  regardless  of  this  shortfall, 
enhance  by  saveral  orders  of  magnitude  the  value  to  the 
force  of  radar  "a"  or  weapon  "b,"  in  comparing  their  net 
effectiveness.  This  comparison  is  presented  in  relation  to 
the  ether  comparable  systems  in  the  force  to  provide  a 
comprehensive,  "net"  effectiveness  display. 

I.  1SSII  HANAGEBEHT  EECISICI  SUPPORT  SISTEH 

This  thesis  is  organized  into  three  chapters;  an  intro¬ 
duction,  a  discussion  of  the  software  development,  and 
finally,  a  comprehensive  User's  Manual  for  operation  of  the 
system.  It  is  essential  to  point  out  at  this  juncture,  the 
design  has  attempted  to  maximize  the  ease  with  which  a  user 
interacts  with  the  system,  and  therefore,  the  User's  Manual 
can  assuire  a  more  appropriate  application  as  a  reference 
rather  than  a  mandatory  prerequisite  for  operation. 

The  battla  group  assets  addressed  in  this  DSS  are  those 
commonly  fcand  in  a  carrier  or  surface  battle  group,  with 
their  supporting  Service  Force  ships.  In  the  interest  of 
economy,  for  a  carrier  battle  group,  only  fighter  and  SEW 
airwing  assets  are  considered.  The  general  functioning  of 
the  ESS  is  initiated  with  the  input  of  the  names  of  the 


ships  which  will  confess  the  battle  group.  The  ship  rases, 
in  turn,  are  the  key  elements  of  database  records,  which  are 
reflective  cf  that  skip's  senscr,  weapons,  and  UHF/HF  ccmmu» 
nicaticns  capabilities.  To  afford  naximum  dissemination  of 
not  only  this  thesis,  but  also  the  DSS  concept,  the  ship 
databases  bave  been  developed  from  unclassified  sources. 
However,  the  design  of  the  files  containing  the  data, 
readily  facilitates  the  transition  to  a  classified  database. 

The  focus  of  this  DSS  is  to  afford  the  battle  group 
commander  a  vehicle  whereby  he  can  "build"  a  battle  group 
from  specific  units  with  their  specific  capabilities  and  not 
typical  class  capabilities.  Whether  it  be  a  theoretical 
formation  cf  a  group  of  representative  ship  types,  or  a 
composition  of  task  organized  units,  the  system  will  orga¬ 
nize  and  display  the  performance  capabilities  of  the 
sensors  and  weapons  which  are  organic  to  the  developed 
group.  The  operations  of  the  DSS  revolve  around  estab¬ 
lishing  the  positions  of  the  ships  from  designated  "ZZ" 
position,  then  allowing  the  user  to  display  to  the  terminal 
screen  specified  weapons  and  sensor  capabilities,  as  well  as 
displaying  to  the  graphics  monitor  the  translation  of  equip¬ 
ment  capability  intc  coverage  or  effectiveness  areas  for 
each  asset.  A  distinction  is  made  here,  between  terminal 
screen  and  graphics  monitor,  as  the  system  can  accomodate 
two  categories  cf  installations;  those  with  a  graphics 
interface,  and  those  without.  While  the  design  encompasses 
a  full  graphics  display  capability,  with  the  terminal 
displays  providing  supplemental  views,  the  supplemental 
views  are  comprehensive  and  can  stand  alone  should  the  user 
have  nc  graphics  capability.  For  operation  of  the_  DSS 
without  a  graphics  capability,  the  user  st.uld  refer  to  the 
introductory  sections  of  the  User's  Manual. 

With  the  graphics  capability,  once  the  coverage  arsas 
have  been  displayed,  the  user  can  expand  the  detail  of  the 
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view  by  displaying  a  cartesian  coordinate  grid  and/or  an 
appropriate  threat  sector.  Additionally,  with  an  aye 
towards  projecting  the  tactical  impact  of  moving  a  unit,  the 
user  is  afforded  the  opportunity  to  manipulate  the  positions 
cf  the  force  units  and  observe  the  subsequent  change  in 
force  senscr  or  weapons  coverage  effectiveness. 

Hers  to  sards  the  administrative  aspects  of  battle  group 
operations,  the  Composite  Warfare  Commander  (CMC)  organiza¬ 
tion  can  be  constructed,  managed,  and  changed. 
Additionally,  a  real  time  view  of  the  composition  of  the 
various  circuits  in  the  battle  group  communications  plan  is 
available.  In  the  COHHS  module  of  the  DSS,  the  communica¬ 
tions  nets  can  be  displayed  with  the  participating  units,  as 
dictated  by  mission  area,  shown.  An  extension  of  the 
communications  views  is  a  comparison,  on  the  UHF  nets,  of 
the  units  who  are  out  of  UHF  comm  range  with  the  Net  Control 
Station.  A  final  administrative  capability  of  the  system 
is  allowing  the  user  to  enter  explanatory  remarks  for  a 
unit,  to  be  included  in  that  units  database  for  future 
access/display. 

6.  FCLIC1-CH  EHHAICEHEHTS 

The  primary  goal  of  this  thesis  has  been  to  initially 
develop  an  interactive  Decision  Support  System,  controlled 
through  voice  technology,  which  facilitates  a  battle  group 
commander's  management  of  his  assets.  There  are  several 
enhancements  to  this  CSS  which  could  be  addressed  by  future 
efforts. 

•  Conversion  to  Connected  Speech  Voice  Technology 

•  Incorporation  of  SHARPS  and  IREPS  data  as  alternatives 
to  tie  system  default  senscr  capabilities 


•  Eipansicn  of  the  database  and  display  capabilities  to 
alien  display  of  the  opposition  sensors  and  weapons  on 
the  sane  view 

•  Conversion  of  the  software  to  micro-con puter/desk  top 
use 

•  Adaptation  of  the  DI-3000  "Pick”  function  allowing  iden¬ 
tification  of  monitor  coordinates  from  a  "Byte  Board" 
device 

•  Incorporation  of  perforaance  models  which  would  drive 
the  positioning  of  the  force  units 

•  Interface  with  a  wargane  to  allow  representation  of 
capability  displays  unique  to  the  composition  of  the 
battle  group  in  use 

•  Incorporation  of  napping  libraries  to  allow  display  of 
capabilities  with  respect  to  a  specific  geographic  area 
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II.  DfCISIOI  S  DIPOST  SYSTEM  SOPH  ABB  DB?EIOPflE»T 


1.  IBTBCDOCTIOR 

The  previous  chapter  discussed  the  rationals  for  the 
development  of  this  thesis,  as  veil  as  structure,  and  seme 
cf  the  key  components  of  the  design  utilized.  This  chapter 
addresses  the  development  of  the  software  which  supports  the 
Cecisicn  Support  System.  The  discuss:  on  will  cover  the 
schema  utilized  for  the  system,  definitions  of  common  system 
variables,  as  well  as  a  general  overview  of  the  construct  of 
the  system  modules.  It  is  intended  that  this  chapter  be 
utilized  in  concert  with  the  system  program  (not  attached  to 
this  paper)  ,  which  is  written  with  algorithmic  descriptions 
incorporated  intc  each  program  unit. 

E.  PBCBIEH  FOBMULAT3C1 

The  fundamental  challenge  of  this  thesis  was  to  develop 
a  functional  support  system  for  a  battle  group  commander. 
This  system  was  to  previde  for  the  display  of  specific  force 
databases,  as  well  as  be  capable  of  translation  of  certain 
capabilities  in  those  databases  into  discernible  computer 
graphics  displays.  Parallel  to  these  efforts,  development 
cf  a  functional  user  -  computer  dialogue  format  was  consid¬ 
ered  essential.  In  short,  therefore,  this  thesis  addressed 
the  challenge  of  developing  an  interactive  computer  database 
management/ computer  graphics  system,  which  was  "user 
friendly,"  and  incorporated  the  capabilities  of  today's 
battle  groups. 


C.  SOLUTION  STRUCT OBI 


The  program  was  written  in  FORTBAN-77,  American  National 
Standard  (ANSI  X3.9-1978),  with  extensions  developed  by 
Digital  Eguipaent  Corporation  (DEC)  [Bef.  5]  for  execution 
cn  a  VAX  11  or  PDP-11  series  computer.  Additionally,  the 
DI-3000  graphics  language  is  utilized  for  the  graphics 
unique  capabilities  cf  the  system.  The  control  medium  for 
this  system  accomodates  commands  from  the  terminal  keyboard, 
as  well  as  commands  entered  through  discrete  speech  voice 
recognition  equipments.  The  Threshold  Technology's  T-600 
was  the  vcice  input  device  for  this  program.  However,  any 
compatible  equipment  could  be  utilized.  The  graphics 
output  was  generated  on  RAMIEK  high-resolution  graphics 
interfaces  and  monitors. 


D.  EBOGBAH  GENERAL  SCHEMA 

For  the  ease  of  software  design  and  program  testing, 
this  system  was  designed  around  the  construction  of  eight 
(8)  major  modules.  with  the  exception  of  the  "MAIN 
nodule,"  each  module  comprises  an  assemblege  of  subroutines 
which  focuses  on  the  features  incorporated  in  that  module. 
In  cases  where  a  subroutine  is  requirad  by  more  than  three 
(3)  sections  of  the  program,  that  subroutine  was  included  in 
a  general  section,  at  the  end  of  the  program.  As  an  exten¬ 
sion  of  the  program  itself,  succeeding  topics  in  this 
section  will  address  the  design  of  each  module  group.  In 
addition,  a  glossary,  by  block  common  designations,  will  be 
provided  to  facilitate  following  rhe  flow  of  the  program. 


E.  SIGNIFICANT  ADJUSTNENTS 

There  were  five  principle  areas  which  were  cumbersome  in 
the  development  cf  this  program.  They  are  enumerated  below 
with  mention  of  the  vehicles  by  which  they  were  overcome. 
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a.  Management  of  the  Databases 


There  were  four  databases  developed  for  this 
system.  The  first,  the  Master  Database,  contained  coded 
capabilities  for  130  Pacific  Fleet  units,  with  seme  addi¬ 
tions  to  provide  AEGIS  assets.  This  database  was  oriented 
around  the  name  cf  a  particular  ship.  The  database  would 
be  utilized  by  the  user,  in  identifying  the  name  of  a  battle 
group  unit,  and  the  system  locating  the  record  associated 
with  that  ship  and  reading  the  record.  For  ease  of  manage¬ 
ment,  an  indexed- keyed  access  format  was  utilized  for  this 
file.  The  primary  key  field  was  the  name  of  the  ship. 
The  secondary  key  fields  were  the  first  two  and  first  three, 
respectively,  characters  of  the  unit's  hull  designation. 
The  secctdary  keys  were  so  devised  to  enable  distinction 
between  guided  missile  equipped  units  and  those  which  were 
not.  The  DEC  extensions  which  address  these  capabilities 
are  discussed  below. 

The  second  database  was  incorporated  into  the 
system  to  allow  the  user  to  use  the  short  form  name  of  a 
Ship,  for  example,  "FOSTER"  for  "PAUL  F  FOSTER, "  or  "CONNIE" 
for  "CONSTELLATION. "  This  distinction  was  important,  as  the 
master  database  utilized  the  full  name  of  the  included 
ships.  This  database  file  was  also  formatted  in  a  keyed 
indexed  manner. 

The  third  database  was  actually  a  group  of  three 
files  which  contained  the  database  elements  for  the  partic¬ 
ular  tattle  group,  which  were  developed  by  the  user.  These 
files  used  a  sequential  access  method. 

Finally,  the  communications  circuits  in  the 
tattle  group  COMM  plan  were  stored  in  a  seperate  database  or 
file.  The  composition  of  this  file  was,  again,  a  keyed 
indexed  organization,  based  on  a  primary  key  of  circuit  ID 
numbers.  The  file  contained  the  ID,  circuit  name, 
frequency  range,  and  net  control  station. 


26 


(1)  Indexed/Reved  Organization  Access. 
Becords  in  an  indexed  file  are  ordered  by  the  fields  of 
those  record  elements  designated  as  key  fields.  This  orga¬ 
nization,  then,  specifies  the  order  of  processing  of  the 
records  in  the  file.  You  sust  specify  the  locations  within 
the  records  of  the  primary  key  field  (mandatory) ,  and  any 
alternate  key  fields.  Once  the  record  corresponding  to  the 
identified  key  has  been  located,  this  organization  type 
allows  sequential  access  to  succeeding  records  in  that  file 
if  desired.  [Bef.  5:  pp.  7-3  to  7-5] 

t.  Correcticn  of  a  Capability  in  the  Master 

Database 

There  were  foreseeable  situations  where  a  change 
in  a  unit's  capability  was  to  be  incorporated  into  the 
Master  Database.  This  eventuality  is  accomodated,  by 
allowing  manual  input  of  the  change  in  capability.  In 
order  to  adjust  the  Master  Database  to  reflect  this  change, 
a  REWRITE  feature  was  utilized. 

(1)  BEWBITE  a  Becord  ia  3  Indexed/Keyed  File. 
The  BEWBITE  feature  transfers  output  data  from  internal 
storage  into  the  current  record  in  an  indexed  file.  You 
must  first  locate  tke  record  you  desire  to  change,  with  a 
BEAD  statement,  then  REWRITE  will  update  the  record  as  you 
have  indicated.  In  this  program,  only  FORMATTED  REWRITE 
statements  were  utilized,  indicating  that  the  record  had  a 
specific  format  associated  with  the  data  entries.  [Ref.  5: 
p.  7-37] 

c.  Conversion  of  Ship  Name  into  Graphics  Integer 

Form 

Unique  to  the  DI-3000  graphics  language,  the 
text  prixitives  displayed  on  th9  monitor  are  required  to  be 
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in  intar sal/integer  fora.  The  difficult;  arose  when  the 
ship’s  names,  which  were  C8ABACTER*19  variables,  were 
required  to  be  displayed  along  with  the  force  capabilities. 
The  necessary  conversion  of  these  character  variables  to 
internal  fora  was  accomplished  through  the  use  of  the  DECODE 
extension. 


(1)  DECODE  Operations.  The  DECODE  statement 
allows  tte  conversion  of  character  variables  into  internal 
(binary)  fora  according  to  a  specified  format  statement. 
For  display  to  the  graphics  monitor,  the  names  of  the  ships 
were  transformed  from  their  character  form,  and  segmented 
into  a  five  element  integer  array  which  was  the  useable  form 
for  display.  [  Ref.  Ss  pp.  1-1  to  1-2] 

d.  Segmenting  a  Multi-Element  Command  String 

In  several  of  the  display  modules,  the  number  of 
available  options  reguired  the  system  to  be  able  to  discrim¬ 
inate  the  key  portions  of  multi-element  commands.  An 
example  of  this  requirement  is  reflected  in  the  command 
string  "CISELAY  OMIT  SIMITZ."  Each  component  of  this  three 
element  command  was  selected  from  several  options.  These 
options  additionally  were  of  differing  lengths.  The 
system,  therefore,  had  tc  break  the  command  into  these 
components.  The  command  was  read  into  the  system  as  a 
thirty-four  (34)  element  integer  array,  and  through  the  use 
of  the  EBCODE  extension,  the  program  converted  each  of  the 
appropriate  command  elements  into  their  proper  character 
formats. 


O)  SffCCSE  Operations.  The  functioning  of  the 
ENCODE  extension  is  identical  to  that  of  the  DECODE  func¬ 
tion,  only  in  reverse.  The  integer  command  string  was 
first  broken  into  segments,  with  the  position  of  the  spaces 
indicating  a  new  element.  Next,  each  of  these  integer 
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segments  was  transfcrned  into  character  fora  according  to 
the  fcraat  required  for  the  particular  command  element. 

(Ref.  5:  pp.  1-1  to  1-2] 

1  •  Orientation  $f  Ship  Karnes  on  Graphics  Plot 

Depending  on  the  scale  in  use  when  the  graphics 
capabilities  of  the  system  ware  utilized,  a  great  deal  of 
clutter  reduced  the  effectiveness  of  the  display.  This  was 
predominately  due  to  the  congestion  involving  ship  names  in 
close  proximity.  This  clutter  was  reduced  by  orienting  the 
name  of  the  ship  comnensura te  with  its  relative  position  in 
the  display.  The  subroutine  "ORIENT,"  to  be  discussed 
later,  made  a  comparison  of  the  position  of  the  unit  to  be 
displayed,  with  respect  to  the  plot  quadrant  it  was  in. 
Eased  cn  the  result  of  this  comparison,  the  DI-3000  "JJUST" 
call  was  controlled  to  reduce  the  numbers  of  overlapping 
names.  The  function  of  the  "JJOST"  subroutine  in  the 
EI-3000  language  is  to  orient  the  display  of  text  at  the 
position  specified.  The  call  to  this  routine  will  cause 
the  text  to  be  "justified"  at  its  center,  left,  or  right 
sides,  as  well  as  with  respect  to  tha  top  or  bottom  of  the 
letters  in  the  text. 

I.  DSS  II1E  COHPOSITIOI 

This  Decision  Support  System  residas  in  the  wargaming 
Analysis  and  Wargaming  Laboratory  (WARLAB)  at  the  Naval 
Postgraduate  School.  The  user  name  under  which  it  is  oper¬ 
ated  is  called  "DECISION."  Should  this  user  account  not  be 
available  on-line,  tfce  complete  system  is  available  on  tape 
in  the  Lab.  The  main  program,  object,  and  execution  files 
all  have  the  "DSS"  name  associated  with  them.  The 
following  files  support  the  operations  of  the  system  and  are 
organic  to  this  account. 
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•  fCgQII .CAT  -  This  file  contains  the  aaster  database 

for  the  DSS.  The  database  is  a  formatted,  keyed  access 
file  as  discussed  above.  It  is  from  this  file  that  the 
program  Kill  automatically  locate  the  database  for  the 
ship  identified,  and  transfer  that  data  into  the  battle 
group  operating  databases. 

•  1 CHQ12. DAT  -  This  file  is  a  keyed  access  formatted 

file  which  contains  the  short  form  names  of  some  of  the 
ships  in  the  aaster  database.  When  the  system  searches 
the  Haster  Database  to  extract  the  capabilities  of  a 
unit,  should  a  name  match  not  occur  in  this  search,  the 
system  will  first  check  this  file  for  a  short  fora  name 
match  and  conversion  to  the  full  fora  name,  before  the 
unit  will  be  "flagged"  for  manual  database  entry. 

•  I CHOC 7. CAT  -  This  file  is  created  through  the  func¬ 

tioning  of  the  system.  A  "SAVE"  capability,  allows  the 
user  to  store  the  data  which  he/she  has  developed,  and 
terminate  the  session,  resuming  it  at  a  later  time. 
This  file  is  sequentially  organized  and  contains  control 
variables,  number  of  ships  in  the  battle  group  and  their 
names.  It  is  used,  when  the  user  next  initiates  a 
session  with  the  system,  to  reaffirm  that  a  battle  group 
had  been  formed  previously. 

•  FCfiO<;8. DAT  -  This  file  is  also  generated  when  the 

"SAVE"  feature  is  exercised.  In  addition  to  the  names 
of  the  units,  as  was  available  in  FOR007.DAT,  this  file 
alsc  contains  the  complete  database  for  the  units 
designed  into  the  particular  battle  group.  This  is 

what  is  referred  to  in  the  system  as  the  "battle  group 
database."  It  is  read  into  the  system,  and  is  orga¬ 
nized  through  the  use  of  linked  lists.  A  representa¬ 
tive  record  in  this  file  is  more  comprehensive  than  its 
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counterpart  in  tie  aaster  database.  This  database  will 
reflect  current  capabilities,  as  well  as  user  generated 
information  as  to  unit  position,  explanatory  remarks, 
etc.  This  file  is  sequentially  organized. 

•  FCB0C9. CAT  — -  This  is  the  third  file  generated  by 

exercising  the  "SAVE"  feature  of  the  systen.  The 

Ccepcsite  Warfare  Commander  organization  is  stored  here. 
The  contents  of  this  file  are  the  names  of  the  warfare 
ccmmanders/coordinators ,  the  respective  organizations 
functioning  in  these  capacities,  and  the  unit  on  which 
the  respective  ccmmander/coordinator  is  embarked.  The 
file  is  sequentially  organized. 

•  FCB0 19. DAT - The  communications  plan  structure  is 

ccctained  in  this  resident  file.  As  with  the  master 
database  (FOBOI 1 .EAT) ,  this  file  is  referenced  from  the 
CCHHS  Module,  however,  the  information  contained  therein 
is  net  transferred  to  DSS  for  manipulation.  This  file 
has  a  keyed  indexed  organization  based  on  the  primary 
key  of  circuit  IE  number.  The  remainder  of  9ach  record 
certains  the  name  of  the  net,  the  net  control  station, 
the  frequency  range,  and  the  applicable  mission  area  for 
which  this  net  is  used. 

6.  BLCCK  COMBOS  VARIABLE  DEFIBITIONS 

In  an  effort  to  minimize  the  necessity  for  passing  large 
numbers  cf  variables  between  using  subroutines,  extensive 
use  was  tade  of  "Block  Common"  constructions.  These  blocks 
grouped  those  variables  whose  use  was  similar,  and  whose 
data  type  was  the  sane.  As  a  reference  to  be  utilized  when 
reading  the  program,  the  following  sections  address  each  of 
these  blocks  and  define  the  variables  which  are  contained 
therein.  It  is  not  the  intent,  however,  that  a  complete 
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discussion  of  the  range  of  possible  variable  values  be 
included.  For  a  comprehensive  review  of  the  values  which 
the  variables  could  assume,  reference  should  be  made  tc  the 
User's  Manual,  chapter  three  of  this  thesis.  The  array 
dimension  cf  the  particular  variable  is  shown  in  paren¬ 
theses. 

a.  BDAT1  HUMSHP  ,  FIRST,  FREE,  LINK  (25) 

This  block  groups  the  basic  integer  data 
regarding  the  organization  of  the  battle  group  database. 
The  definitions  of  the  variables  contained  in  this  block  are 
as  fellows. 

•  HUMSHF  -  Humber  of  ships  in  the  battle  group 

•  FIRST  -  Header  for  the  battle  group  database  linked 

list 

•  FREE  -  The  first  available  record  position  in  the 

battle  group  database 

•  LINK  —  Battle  group  database  link  values 

b.  BD&T2  - HULL  (25),  UNIT  (25),  REMARKS  (25) 

This  block  contains  the  complement  to  the 
integer  base  data  for  the  battle  group  database,  the  base 
character  variables.  The  definitions  of  these  variables 
are  as  fellows. 

•  HUH  —  A  *6  variable  representing  the  hull  number  of 
the  ship 

•  CHIT  —  A  *19  variable  represanting  the  name  of  the 
ship. 

•  REMARKS  —  A  *25  variable  cf  a  general  nature,  input 
by  the  user  as  descriptive  remarks  about  the  respective 


C.  P0SIT1  —  COS  YS ,  ZZ  QOAD(25) 

This  block  organizes  one  of  the  two  positioning 
variable  groups,  and  represents  the  character  variables 
involved  with  the  ship  positions.  There  is  an  additional 
position  block  which  is  unique  to  graphics  displays  and  is 
addressed  seperately.  The  following  is  the  composition  of 
this  block. 

•  COSTS  —  A  *5  variable  indicating  the  type  of  coordi¬ 
nate  system  in  use  (polar  or  cartesian) 

•  ZZ  —  A  *19  variable  indicating  tThe  name  of  the  unit 
at  "ZZ" 

•  QOAE  —  A  *1  variable  indicating  the  position  quadrant 
of  a  unit  (implies  cartesian  positions  are  being  used) 

d.  POSIT2  -  XPOS  (25)  ,  XPOS(25),  BHNG  (25)  , 

RNG  (25) ,  SPEED (25) 

This  block  complements  the  previous  variable 
grouping  with  the  integer  variables  associated  with  the 
positioning  of  the  ships.  The  composition  of  the  block  is 
as  fellows. 

•  XPOS  —  The  position  of  the  ship  in  the  "x"  direction 
(implies  the  use  of  cartesian  coordinate  system) 

•  TPOS  —  The  position  of  a  ship  in  the  "y"  direction 
(implies  the  use  of  cartesian  coordinate  system) 

•  EBNG  —  The  bearing  of  a  ship  from  "ZZ"  (implies  the 
use  of  the  polar  coordinate  system) 

•  ENG  —  Th6  ranee  of  a  ship  from  "ZZ"  (implies  the  use 
cf  the  polar  coordinate  system) 

•  SPEED  —  The  maximum  speed  of  a  ship 


«.  ADR  INI  -  CRUDES  (25)  ,  DESRON(25) 

This  block  in  eludes  the  character  variables 
which  represent  the  elements  of  the  administrative  organiza¬ 
tion  of  a  unit’s  database.  The  conposition  of  this  block 
is  as  fellows. 

•  CRUDES  —  The  cruiser  destroyer  or  carrier  group  to 
which  a  ship  is  assigned 

•  DESBON  --  The  destroyer  squadron  to  which  a  ship  is 
assigned  (not  applicable  tc  aircraft  carriers  or  service 
fcrce  ships) 

f.  ADMIN2 - P  REAR  (25)  ,  SCHAR(25) 

This  block  contains  the  primary  and  secondary 
■issicn  areas  of  a  ship.  These  are  character  variables. 
The  ccmpcsition  cf  the  block  is  as  follows. 

•  ERMAR  —  A  *3  variable  representing  the  primary 

mission  of  a  ship 

•  SCMAH  —  A  *3  variable  representing  the  secondary 
mission  of  a  ship 

g.  SCHRDR  —  SRSCH(25),  ARSCHA(25),  ARSCHE  (25) 

This  block  represents  the  search  radars  in  the 
database.  These  are  integer  variables,  and  the  composition 
cf  the  block  is  as  fellows. 

•  SRSCH  —  The  variable  representing  the  surface  search 
radar  onboard  a  ship 

•  ARSCHA  —  The  variable  representing  the  primary  air 
search  radar  onbeard  a  ship 

•  ARSCHE  —  The  variable  representing  the  secondary  air 
search  radar  (as  applicable)  onboard  a  ship 


h.  WEAPN1  —  PHAL  (25)  ,  GUN  (25)  MYSLA(25), 

BY  S  L  B  ( 2  5 ) 

The  parameters  cf  the  weapons  capabilities  of 
the  database  are  represented  in  this  block.  These  are 
integer  variables,  and  the  composition  of  the  block  is  as 
follows. 

•  PHAl  —  The  number  of  PHALANX  systems  onboard  a  ship 

•  GUN  —  The  variable  representing  the  type  of  gun 

system  onboard  a  ship 

•  HYSLA  —  The  variable  representing  the  type  of  primary 
aissile  system  (as  applicable)  onboard  a  ship 

•  HYSLB  —  The  variable  representing  the  type  of  secon¬ 
dary  aissile  system  (as  applicable)  onboard  a  ship 

i.  WEAEN2  -  HASP  (25),  TOMA  (25),  SLO  (25) 

This  block  contains  the  character  variable 
complement  of  the  weapons  block  above.  The  composition  of 
this  block  is  as  follows. 

•  HAH E  —  A  *1  variable  (Y/N)  indicating  whether  a  ship 
has  a  HARPOON  capability 

•  TOMA  —  A  *1  variable  (Y/N)  indicating  whether  s  ship 
has  a  TOMAHAWK  capability 

•  SLQ  —  A  *1  variable  (Y/N)  indicating  whether  a  ship 
has  an  AN/SLQ-32  capability. 

j.  HPNRDR  —  ? CSA  (2  5),  FCRB  (25) 

The  fire  control  radar  capability  of  a  ship  is 
represented  in  this  block.  These  are  integer  variables, 
and  the  composition  cf  the  block  is  as  follows. 

•  ICR  A  —  The  variable  representing  the  primary  fire 
control  radar  (as  applicable)  onboard  a  ship 
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•  FCBE  —  The  variable  representing  the  secondary  fire 
control  radar  (as  applicable)  onboard  a  ship 

k.  COHH  —  SAT (25)  ,  0HF(25),  HF  (25)  , 

UHFAVL  (25)  ,  HFAVL(25) 

This  block  contains  the  communications  capabili¬ 
ties  cf  the  ships  in  the  battle  group.  These  are  integer 
variables,  and  with  the  exception  of  the  SAT  variable, 
represent  the  actual  number  of  equipments.  The  composition 
of  this  block  is  as  fellows. 

•  SAT  —  The  variable  indicating  the  type  of  satellite 
communications  capability  (as  applicable)  onboard  a  ship 

•  DBF  —  The  nuxber  of  DBF  radios  installed  onboard  a 
ship 

•  Ef  —  The  number  of  HF  radios  installed  onboard  a  ship 

•  CHFAV1  —  The  number  of  OHF  radios  available  onboard  a 
ship 

•  HF  —  The  number  of  HF  radios  available  onboard  a  ship 
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I.  WPNASW1 


ASWROC  (25) 


This  blcck  represents  the  character  variable 
indicating  the  type  cf  ASH  rocket  onboard  a  ship,  as  appli¬ 
cable,  The  representation  of  this  variable  is  "A"  for 
ASBOC,  MS"  for  SOBROC,  or  "  N"  for  NOT  CAPABLE. 

n.  WPNASW2  -  TOE  E  (25) 

This  block  contains  the  integer  variable  repre¬ 
sentation  of  the  type  of  torpedo  onboard  a  ship.  The 

composition  of  the  variable  is  M1M  for  MK-46,  "2”  for  MK-48, 
or  "0"  for  NOT  CAPABLE. 

C.  AIBCAP  —  H  ELC  (25)  ,  EMB(25) 

This  block  addresses  the  aircraft  capability  of 
the  tattle  group  with  respect  to  type  of  helicopters  avail¬ 
able  within  the  force.  The  composition  of  this  block  is  as 
folic  VS • 

•  HEIO  --  A  *1  variable  indicating  the  type  of  helicopter 
capability  a  ship  has  onboard 

•  EEB  —  A  *1  variable  (Y/N)  indicating  the  emtarcation 
status  of  a  ship  which  is  helicopter  capable 

p.  COMAND  -  CMD  (8)  ,  ORG(8),  EMBARK  (8) 

This  block  contains  the  composition  of  the  CWC 
Organization.  The  representations  of  these  character  vari¬ 
ables  axe  as  follows. 

•  CUD  —  A  *5  variable  representing  the  name  of  a  warfare 
ccamander/cocrdinator  —  this  value  is  fixed  in  the 
ELOCK  EATA  secticn  of  the  program 

•  OBG  —  A  *25  variable  representing  the  name  of  the 
organization  functioning  as  a  warfare  commander/ 
coordinator 
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•  EBEARK  —  1  *19  variable  indicating  the  name  cf  the 

ship  on  which  the  warfare  commander/coordinatcr  is 
exbarked 

g.  RAM  1  —  OR  D  (31)  ,  ABS(37),  SCALE,  SIZE, 

CHARTS  HIE 

This  block  con  tains  real  variables  which  are 
utili2«d  in  the  graphics  portions  of  the  program.  They 
relate  to  the  graphics  plot  parameters  associated  with  the 
display  capability  of  this  DSS.  With  the  exception  of  the 
OPO  and  ABS  variables,  these  values  are  fixed  in  the  BLOCK 
EATA  section  of  the  program.  The  composition  of  this 

ccsscn  block  is  as  fellows. 

•  ORE  —  Plot  "x"  position  of  a  ship  or  display  feature 
(1-25  —  ships,  26-35  --  ship  temporary  positions,  36-37 
—  AER/CAP  features) 

•  ORD  —  Plot  wy"  position  of  a  ship  of  display  feature 
(1-25  —  ships,  26-35  --  ship  temporary  positions,  36-37 
--  AIR/CAP  features) 

•  SCALE  —  The  scale  (1-5)  controlling  the  dimensions  of 
the  display  coverage 

•  SIZE  —  A  scaling  factor  applied  to  displayed  graphics 
text  primitives  used  tc  maintain  balance  with  the  plot 
dimensions 

•  CHAR^SHIP  --  A  control  variable  used  as  the  basis  for 
the  size  of  the  ship  name  text  primitives  displayed  on 
the  screen 

r.  BASP0S1  —  EASQUAD 

This  blcck  contains  the  character  variable 
representing  the  quadrant  in  which  the  ship  functioning  as 
WZZ  is  positioned.  The  variable  is  utilized  in  the  compu- 


tation  of  the  graphics  equivalent  positions  of  the  remainder 
cf  the  ships  in  the  tattle  group. 

S.  BASPOS2  -  BASOBD,  BASABS,  POSX,  POSY 

This  block  contains  the  integer  (BASOBD, BASABS) 
and  real  (PCSX,  POSY)  variables  which  are  utilized  to  orient 
the  graphics  plot  to  the  position  of  the  "ZZ”  ship.  It  is 
also  used  in  computing  the  required  offset  for  the  display 
of  the  cartesian  coordinate  grid,  an  option  in  the  graphics 
portions  of  the  DSS.  The  composition  of  the  block  is  as 
follows. 

•  BASOBD  —  The  "x"  position  of  the  ship  at  HZZ" 

•  E  AS  AES  —  The  "y"  position  of  the  ship  at  "ZZ" 

•  PCSX  —  The  graphics  plot  Mx"  coordinate  for  the  origin 
cf  the  cartesian  grid  display 

•  PCS Y  --  The  graphics  plot  "y"  coordinate  of  the  origin 
of  tie  cartesian  grid  display 

t.  VIBTOAL  LEFT,  BIGHT,  DP,  DOWN,  LPORT, 

BPOBT,  OFCBT,  D  POST 

This  blcck  contains  the  parameters  associated 
with  the  definition  of  the  graphics  display  plot.  They  are 
tied  tc  the  DI-3000  inputs  addressing  the  WINDO  size  and  the 
VIE WPCBT  size.  These  are  real  variables  and  their  values 
are  fixed  in  the  BLCCK  DATA  section  of  the  program.  The 
composition  of  the  blcck  is  as  follows. 

•  LEET  The  left  dimensional  limit  for  the  WINEO  of 

the  graphics  display 

•  BIGHT  —  The  right  dimensional  limit  for  the  WINDO  of 
the  graphics  display 


•  OE  —  The  upper  dimensional  limit  for  the  HINDO  of  the 
graphics  display 

•  DOWN  --  The  lower  dimensional  limit  for  the  WINEO  of 
the  graphics  display 

•  LEOB1  —  The  left  dimensional  limit  for  the  VIEWPORT  of 
the  graphics  display 

•  BEOBT  — *  The  right  dimensional  limit  for  the  VIEWPORT 
of  the  graphics  display 

•  OEOB1  —  The  upper  dimensional  limit  of  the  VIEWPORT  of 
the  graphics  display 

•  DEOBT  —  The  lower  dimensional  limit  for  the  VIEWPORT 
of  the  graphics  display 

H.  HOODIE  COHPOSXTIC1  AID  CAPABILITIES 

The  following  sections  of  the  chapter  will  address  the 
general  composition  and  capability  of  each  of  the  modules  in 
this  program.  Within  the  discussion  of  each  module,  a 
brief  description  of  the  purpose  of  each  subroutine  within 
that  module  will  be  presented.  This  section  is  intended  to 
be  utilized  in  conjunction  with  the  DSS  computer  program. 

1.  HAIN  Module 

The  HAIN  module  is  the  program  unit  which  serves  as 
the  substructure  upon  which  the  remainder  of  the  system  is 
formed.  The  module  is  oriented  around  a  BLOCK  I?  construc¬ 
tion  which  discriminates  among  the  options  (system  modules) 
presented. 

2 .  EUIID  Module 

The  BOILD  module  of  this  program  allows  the  user  to 
build  a  local  battle  group  database  composed  of  ships  which 


the  user  designates.  additionally,  this  nodule  functions 
as  the  pcint  fron  which  the  user  can  INSERT  or  DELETE  a  ship 
fron  the  battle  group.  The  BUILD  subroutine  will  differen¬ 
tiate  between  the  user's  desires  to  develop  the  database  for 
an  entire  force,  or  cake  individual  changes  to  an  existing 
structure,  through  the  use  LOGICAL  IF  and  BLOCK  IP  construc¬ 
tions.  There  are  two  parameters  which  are  required  by  the 
BUILD  subroutine.  The  first  (SEXIST)  ,  is  a  logical  vari¬ 
able  which  flags  the  existarce  of  a  current  battle  group 
database.  The  seccnd  (FIESTC),  is  again,  a  logical  vari¬ 
able  which  is  changed  in  the  subroutine  to  indicate  that 
this  ncdule  has  been  called.  The  system  requires  that  this 
module  be  called  pricr  to  operations  in  any  other  module 
with  the  exception  of  the  DATAEASE  module,  discussed  later. 
Within  the  EUILD  Module,  the  numbers  and  names  of  the  battle 
group  ships,  as  well  as  their  positions  are  determined. 
The  search  for  the  ship  record  in  a  master  database  is 
accomplished  through  the  SEARCH  subroutine,  organic  to  this 
module.  BUILD  will  also  call  the  MANUAL  subroutine, 
utilized  for  manual  input  of  a  ship'  s  database  if  the  ship 
cannct  be  located  in  the  master  database.  Finally,  from 
this  mcdule,  the  C»C  organization  can  be  developed  through 
the  use  cf  the  CWC  subroutine,  organic  to  the  BUILD  module. 

a.  Position  Subroutine 

This  subroutine  is  utilized  by  several  of  rhe 
system  modules  to  input,  change,  and  display  the  positions 
cf  the  ships  in  the  force.  There  are  four  entry  points 
into  this  subroutine,  controlled  by  a  COMPUTED  GOTO 
construction.  These  entry  points,  specified  by  the  param¬ 
eter  "TARGET"  are  BUILD  module  battle  group  Initialization 
<1)  ,  BUILD  module  INSERT  function  (2),  STATUS  module  (3), 
and  SENSOR  module  («).  This  subroutine  allows  for  the 
specification  of  coordinate  system,  polar  or  cartesian,  and 
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the  position  identification  of  each  ship.  Additionally, 
this  subroutine  develops  the  basic  parameters  upon  which  the 
graphics  coordinate  systea  is  computed.  This  is  done 
through  the  use  of  the  FLOTP  (polar)  or  PLOTC  (cartesian) 
subroutines  in  the  SENSOR  module. 

t.  ewe  Subroutine 

This  subroutine  allows  for  the  initial  estab¬ 
lishment  of  the  CRC  organization  as  well  as  future  display 
cr  ccmponent  changes.  The  design  of  this  subroutine  is 
oriented  arcund  two  COMPOTE D  GOTO  constructions.  The  first 
differentiates  between  which  module  called  the  subroutine, 
Euild  module  CWC  organization  initialization  (1),  STATUS 
module  Display  option  (2)  ,  or  the  STATUS  module  Change 

option  (3)  .  The  second  COMPUTED  GOTO  construction  is 

utilized  tc  orchestrate  movement  through  the  components  of 
the  eight  (8)  warfare  commanders/coordinators  in  the  organi¬ 
zation.  A  key  feature  in  the  operations  of  this  subroutine 
is  the  elimination  of  redundancy  in  the  identification  of 
organizations  and  embarked  units.  The  program  will  attempt 
to  match  an  input  the  user  makes  to  any  of  those  already 

input.  When  a  match  occurs,  say  in  the  naming  of  an 

embarked  unit,  the  program  assumes  the  value  will  remain  as 
previously  specified  and  will  not  query  the  user  tc  repeat 
the  input. 

c.  SEARCH  Subroutine 

This  subroutine  will  search  the  master  database 
(FOR0 11. CAT)  for  the  records  associated  with  the  named 
ships,  and -extract  the  appropriate  record.  This  subroutine 
will  also  use  the  MATCH  subroutine  to  allow  the  user  to 
input  a  short  form  name  for  ship,  convert  it  to  long  form, 
and  reinitiate  the  search. 
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d.  HATCH  Subroutine 


This  subroutine  will  attempt  to  match  a  short 
form  same  of  a  ship  through  the  use  of  file  FOH012.DAT. 

3 .  mm.  IJcduls 

The  STATUS  module  in  the  Decision  Support  System 
allows  tie  user  to  change  an  element  in  a  particular  ship's 
database  record,  change  force  positions,  or  change  an 
element  of  the  CWC  organization.  Additionally,  this  module 
provides  the  vehicle  whereby  the  user  can  display  tc  the 
terminal  screen,  the  positions  of  the  force,  as  well  as  the 
names  cf  the  units  with  specific  weapons  capabilities. 
This  module  is  designed  to  operate  without  the  use  of 
computer  graphics.  The  functioning  of  this  module  is 
oriented  around  the  interpretation  cf  a  thirty  four  (34) 
character  ccmmand  string,  which  is  segmented  through  the  use 
cf  the  ENCODE  fortran  extension,  discussed  earlier.  Each 
command  string  is  broken  into  three  character  variables 
which  respectively  address,  the  major  module  options,  data¬ 
base  ccapcnent  tc  which  this  option  is  to  be  applied,  and 
finally,  the  display  or  category  specifier.  Once  the 
ccmmand  string  has  been  broken  into  the  appropriate 
segments,  the  module  utilizes  BLOCK  IF  constructions  to 
discriminate  between  the  various  segments.  The  STATUS 
subroutine  comprises  the  largest  portion  of  this  module. 

a.  DISDAT  Subroutine 

Organic  tc  the  STATUS  module,  the  DISDAT  subrou¬ 
tine  provides  the  framework  upon  which  the  specific  equip¬ 
ment  names  and  associated  ranges  are  translated  from  the 
codes  utilized  in  the  program  databases.  The  operations  of 
this  subroutine  are  oriented  around  two  general  groupings  of 
COMPUTED  GOTO  constructions.  The  first  differentiates 
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between  the  calling  subroutines  and  directs  program  func¬ 
tions  in  either  an  equipment  display  or  nomenclature/range 
display  direction.  While  this  subroutine  is  principally 
used  by  the  STATUS  module,  it  does  provide  the  terminal 
screen  displays  of  specific  equipments  utilized  by  the 
SENSOB  and  WEAPONS  modules. 

4.  CCHKS  Module 

The  communications  module  is  designed  to  accomplish 
two  objectives.  The  first  function  is  to  manage  the 
numbers  cf  available  radios  onboard  a  ship  for  comparison 
with  the  installed  capability.  Second,  this  module  will 
displaj  the  participants  of  a  specified  communications 
circuit  on  the  graphics  monitor.  The  query/response 
sequencing  is  accomplished  through  the  use  of  menus  from 
which  a  number  entry  is  required  to  specify  a  desired 
option.  Unlike  tbe  SENSOR  and  WEAPONS  modules,  which 
cannct  be  operated  if  a  graphics  capability  does  not  exist, 
the  radic  numbers  maragement  capabilities  of  this  subroutine 
can  be  exercised  without  any  graphics  capability. 

5 .  IJNS08  Module 

This  module  is  totally  reliant  upon  computer 
graphics  for  its  operations.  The  call  from  the  MAIN  module 
to  this  nodule  is  mads  through  a  graphics  control  subroutine 
discussed  later.  This  is  the  reason  that  the  SENSOR  module 
cannct  be  operated  without  a  computer  graphics  capability. 
Within  this  module,  the  user  can  generate  displays  of  the 
coverage  areas  of  specified  force  sensors.  The  identifica¬ 
tion  cf  the  specific  sensor  is  made  in  a  manner  similar  to 
that  used  in  the  STATUS  module.  The  command  string  for 
this  module  is  allocated  3  4  characters  in  length,  and  is 
comprised  cf  two  components  which  are  seperated,  and 
converted  tc  character  representation.  This  is 


accomplished  through  the  use  of  the  ENCODE  Fortran  exten¬ 
sion.  Once  the  secaents  of  the  command  string  are  identi¬ 
fied,  a  BLOCK  IF  construction  is  utilized  to  direct  the 
program  flew  through  the  various  options.  There  are 
numerous  calls  to  EI-3000  unique  subroutines  within  this 
aodule;  however,  the;  will  not  be  discussed. 

a.  PLOT?  and  PLOTC  Subroutines 

While  organic  tc  the  SENSOR  nodule,  these 
subroutines  are  principally  utilized  by  the  POSITION  capa¬ 
bility  of  the  BUILD  aodule.  The  PLOTP /PLOTC  subroutines 
will  translate  the  user's  polar  or  cartesian  positions  for  a 
unit  into  useable  coordinates  for  the  graphics  displays. 
The  PLOTP  subroutine  uses  a  trigonometric  calculation  to 
sake  this  conversion,  whereas  the  PLOTC  subroutine  utilizes 
a  BLOCK  IF  construction  which  makes  a  comparison  to  the  MZZ" 
unit's  "base"  positicn. 

b.  AREA  Subroutine 

The  AR2 A  subroutine  is  the  principle  program 
driver  from  which  the  coverage  areas  of  the  various  force 
sensors  and  weapons  are  generated.  This  subroutine  will 
cause  the  VIEWPORT  tc  be  defined  for  the  coverage  display. 
Additionally,  it  will  convert  the  name  of  a  ship  into  an 
internal  form  useable  by  the  graphics  system,  through  the 
use  cf  the  NANE_CONVERT  subroutine.  AREA  will  call  the 

CISC  AT  subroutine  in  the  STATUS  moduia  to  obtain  tha  range 
for  the  specific  sensor  or  weapon  system  it  is  plotting. 
While  organic  to  the  SENSOR  module,  this  subroutine  is  also 
utilized  by  the  WEAPONS  module. 

c.  ASW_AREA  Subroutine 

This  subroutine  is  a  derivative  of  the  AREA 
subreutine  discussed  above.  The  reason  for  the 


45 


diff erentiation  between  these  two  capabilities  is  that  the 
force  ASW  display  features  are  aore  coaplez  than  thcsa  used 
in  dieplaying  the  radar  coverages.  This  is  because  *rth 
the  1S9  display,  optional  convergence  zone  capabilities  must 
be  identified,  aatched  to  the  sonars  capable,  which  are 
further  aatched  to  those  ships  which  have  those  sonars. 
Similar  to  th9  AREA  subroutine,  AS  W_  ARE  A  will  establish  the 
graphics  VIERPO&T,  convert  the  naae  of  the  ship  into  useable 
graphics  fora,  and  access  the  range  of  the  specific  equip- 
cents  through  the  DZSEAT  subroutine. 

d.  Sensor  Display  —  Title  Generation 

The  generation  of  the  titles  for  the  various 
display  options  in  the  SENSOR  aodula  is  discussed  collec¬ 
tively  for  all  the  nodule  options.  The  following  subrou¬ 
tines  are  used  to  place  the  display  titl9  on  the  graphics 
conitcr:  AIR_.SE ARCH ,  SORE ACE_ SEARCH,  FIRE_CONTROL,  and 
SUB_ SURE ACE.  The  displays  to  which  these  subroutines 
correspond  should  be  evident.  The  operations  of  each  of 
these  subroutines  is  identical.  Each  will  establish  a 
secondary  VIEWPORT  and  WIN  DO  at  the  bottom  cf  the  monitor, 
and  will  display  the  text  primitives  reflective  of  the 
information  shown  on  the  graphics  plot. 

e.  CZ_ ZONE  Subroutine 

The  function  of  this  subroutine  is  to  ascertain 
first,  whether  convergence  zone  sonar  propagations  exist, 
and  second,  if  they  dc,  does  the  unit  being  displayed  have  a 
sonar  capable  of  operating  in  this  mode.  The  determination 
cf  the  existence  of  the  propagation  mode  is  done  through  a 
TES/NC  query  which  establishes  the  value  of  a  logical  vari¬ 
able  which  is  passed  to  the  subroutine.  Once  determined,  a 
COMPUTED  GOTO  construction,  through  the  comparison  with  the 
ccdad  scnar  type  onboard  the  unit  concerned,  generates  a 
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logical  variable  "CCSVEBG,"  which  keys  the  display  of  the 
second  coverage  zone  cn  the  ASH  sonar  display. 

6 .  WEAPONS  Module 

As  its  name  implies,  this  module  is  utilized  to 
display  the  coverage  areas  of  the  force  weapons  systems, 
like  the  SENSOB  module,  REASONS  is  totally  reliant  on  a 
graphics  capability  and  is  invoked  from  the  MAIN  module 
through  a  graphics  control  sequence.  The  module  operates 
from  a  master  menu  where  the  user  selects  a  specific  weapon 
capability  to  be  displayed.  The  langthy  command  strings 
utilized  in  earlier  icdules  do  not  apply  to  weapons.  The 
module  functions  through  the  use  of  a  BLOCK  IF  construction 
discriminating  between  the  various  weapons  capabilities. 
WEAPONS  uses  self-contained  program  code  for  the  generation 
cf  all  available  displays.  This  code  is  identical  to  that 
used  in  the  SENSOB  module,  but  additionally,  allows  for  the 
display  cf  multiple  capabilities  simultaneously,  for  example 
TOHABAWK  and  HARPOON,  or  MISSILE  and  GUN. 

a.  HEAPONS_IABEL  Subroutine 

As  the  nave  implies,  this  subroutine  is  designed 
to  generate  tha  labels  for  the  coverage  displays  selected  in 
the  WEAPONS  module.  A  BLOCK  IF  construction  is  used  to 
create  the  appropriate  label  based  on  the  capability  being 
displayed. 

t.  AS  W— REAPS  Subroutine 

This  subrcutine  displays  the  coverages  for  the 
force  ASW  weapons  systems.  The  subroutine  will  assemble 
and  display  a  coverage  view  reflective  of  each  unit’s  heli¬ 
copter,  ASW-Rocket,  and  torpedo  capabilities.  Each  of 

these  capabilities  are  color  coded  in  the  view. 


7.  I  AT  ABASE  Module 


This  module  sill  display  to  the  terminal  screen,  the 
names  and  hull  numbers  of  the  ships  in  the  master  database, 
grouped  according  to  ship  type.  This  module  is  operated 
through  the  use  of  a  menu  from  which  an  identification 
number  corresponding  to  the  desired  ship  type  is  selected. 
The  mcdule  then  uses  a  COMPUTED  GOTO  construction  to  effect 
the  computation  of  the  key  value  and  key  field  length  neces¬ 
sary  for  accessing  the  appropriate  records  in  the  master 
database. 

8 .  SAVE  Module 

The  purpose  of  this  module  is  to  store  the  developed 
battle  group  database  prior  to  a  session  termination,  should 
the  user  so  desire.  This  mcdule  will  extract  the  database 
values,  and  create  the  three  files  discussed  earlier, 
EOH007.CAT,  EOR008.DAT,  and  FOROQ9.DAT.  Once  these  files 
are  created,  the  module  will  issue  the  FORTRAN  STOP  command, 
thereby  terminating  the  session.  Designed  into  the  schema 
cf  the  DSS  is  a  program  initiated  automatic  save  of  the 
tattle  croup  database  after  initialization  in  the  BUILD 
module.  This  is  done  only  to  provide  a  back-up  should 
power  be  interrupted  tut  will  not  guarantee  permanent  reten¬ 
tion  of  the  database  should  the  user  terminate  his/her 
sessicn  with  a  STOP  command  from  the  MAIN  module. 

9 .  Major  Subroutjqes 
a.  DA  IT  Subroutine 

This  subroutine  is  incorporated  into  every 
module  to  allow  the  user  to  pause  and  take  some  time 
reviewing  the  displayed  information.  Its  construction  is 
simply  providing  instructions  to  ''Press  return,"  and  a  READ 
statement  which  looks  for  an  A1  formatted  variable. 


b.  MANUAL  Subroutine 


This  subroutine  is  lengthy.  It  has  been 
designed  tc  accomplish  two  major  functions.  First,  should 
a  ship  in  the  battle  group  net  reside  in  the  master  data¬ 
base,  this  subroutine  allows  that  unit's  capability  record 
to  be  written  to  both  the  battle  group  database  and  the 
taster  database  (through  the  use  of  the  DATA_CHANGE  subrou¬ 
tine)  .  Tbe  construction  of  this  subroutine  is  oriented 
around  multiple  queries  and  capability  menus.  The  user 
need  only  select  the  appropriate  capability  from  the  menu  to 
include  that  capability  on  the  ship  in  question.  The 
MANUAL  subroutine  is  also  used  by  the  STATUS  module  in 
changing  an  element  of  a  unit's  database  record.  By  desig¬ 
nation  of  the  desired  capability  to  be  changed,  the  appro¬ 
priate  menu  from  this  module  is  displayed  for  capability 
selection. 

c.  CONTBOL  Subroutine 

The  CONTE CL  subroutine  exists  as  the  front  and 
tack  end  program  unit  for  all  graphics  displays.  This 
subroutine  makes  the  foundational  calls  to  the  required 
EI-3000  graphics  routines.  Additionally,  this  subroutine 
will  determine  the  number  of  the  desired  graphics  monitor  to 
be  used.  This  number  is  unique  to  the  KABLAB  at  NPS. 

d.  GHID  Subroutine 

This  subroutine  overlays  a  cartesian  coordinate 
grid  on  the  displayed  capability  coverage  display.  The 
grid  is  scaled  to  the  size  of  the  plot  in  use,  and  its 
origin  is  offset  coanensurate  with  the  cartesian  position 
of  the  unit  at  "ZZ." 
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6.  THREAT  Subroutine 

This  subroutine  creates  a  threat  sector  cn  top 
of  a  displayed  capability  coverage.  The  parameters  for  the 
generation  of  this  sector,  are  the  threat  bearing  and  sector 
width,  both  provided  by  the  user  through  a  query  dialogue 
with  the  system. 

f.  HOVE  Subroutine 

A  major  capability  of  this  DSS  is  to  allow  the 
user  to  experiment  with  the  coverage  display  created  by 
loving  a  unit  and  observing  the  resultant  effect  on  coverage 
that  moving  the  ship's  sensor/weapon  would  have.  This 
subroutine  parallels  the  main  graphics  modules  by  repeating 
their  displays  with  a  designated  new  position  for  a  unit 
identified  by  the  user.  MOVE  will  create  color-coded 
companion  references  to  the  old  position  as  well  as  generate 
legends  for  evaluation  of  the  new  information  being 
displayed.  move  is  only  called  from  the  sensor  or  WEAPONS 
modules. 

g.  COMBAT  subroutine 

This  subroutine  is  used  to  discriminate  between 
surface  combatant  ship  types  and  those  non-combatant  ship 
types.  It  is  called  from  the  MANUAL  subroutine  to  elimi¬ 
nate  the  query  for  a  database  item  not  available  to  the  ship 
type  whose  database  record  is  being  created. 

h.  LIST  Subroutine 

The  LI S I  subroutine  simply  utilizes  the  link 
list  structure  of  the  battle  group  database  to  display  the 
cases  cf  the  units  in  the  battle  group.  This  subroutine  is 
called  whenever  identification  of  a  battle  group  unit  is 
reguired,  tc  assist  the  user  in  making  the  correct  response. 


i.  LOCATE  Subroutine 

This  subroutine  is  utilized  whenever  a  ship  name 
froi  the  battle  group  is  the  desired  input  to  a  query. 
LOCATE  will,  as  its  naae  implies,  locate  the  ship  within  the 
link  list  structure,  flag  it  Mf ound, "  and  pass  the  sequence 
number  cf  the  ship  back  to  the  calling  module.  This 
subroutine  is  used  throughout  the  program. 

j.  NAM  E_CON  VERT  Subroutine 

NAME_ CON  VERT  will  truncate  the  name  of  a  ship 
for  use  in  the  graphics  displays.  This  subroutine  was 
devised  to  eliminate  some  of  the  clutter  generated  by  the 
overlapping  of  the  ship's  names  on  the  plots.  However,  its 
principle  function  is  to  convert  the  name  of  the  ship,  a 
character  variable,  into  an  internal  form  useable  by  the 
01-3000  text  primitives. 

k.  ORIENT  Subroutine 

This  subroutine  compares  the  coordinates  of  the 
ships  graphics  pcsiticn  with  the  quadrant  in  which  it  is  in, 
and  establishes  the  appropriate  justification  values  for  the 
JJtJST  call  in  the  DI-3000  text  output  primitive.  It  basi¬ 
cally  justifies  the  name  to  ensure  it  is  pointing  outward, 
away  from  the  center  cf  the  plct. 

l.  DAT A_CHANGE  Subroutine 

DATA_CHAKGE  will  accomplish  one  of  two  things, 
first,  it  will  writs  a  manually  developed  ship  database 
record  to  the  master  database.  If  the  record  already 

exists, this  subroutine  can  be  used  to  REWRITE  <discussed 
earlier)  the  record  should  the  user  desire  to  make  a  capa¬ 
bility  change  permanent. 
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Now  that  the  design  of  the  program  has  been 
discussed*  the  next  chapter  of  this  thesis  will  address 
utilizing  the  DSS.  The  User's  Manual*  as  has  already  been 
aenticned*  can  be  used  as  a  reference*  or  as  an  instruction 
cn  the  operations  of  the  DSS.  The  DSSdces  explain  enough 
information  that  the  reading  cf  the  User's  Manual  pricr  to 
conducting  a  session  is  not  necessary. 
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III.  DECISION  SUPPORT  SYSTEM  USER'S  BAH DAI 


1.  INTRODUCTION 

Welcome  to  the  Battle  Group  Asset  Management  lecision 
Support  System.  Nee  that  you  are  ready  to  operate  the 
system,  the  topics  that  follow  will  elaborate  on  the  capa¬ 
bilities  of  the  computer  program.  It  is  important  to 

recognize  at  the  outset  that  the  complexity  of  your  interac¬ 
tion  with  the  system  is  NOT  dependent  on  your  having  a 
Computer  Science  degree.  You  cannot  '‘bomb"  the  program  or 
accidentally  damage  any  of  the  databases.  Every  request  for 
information  has  been  protected.  Should  you  inadvertantly 
enter  an  incorrect  character,  the  system  will  recognize  that 
fact  and  ask  you  tc  reenter  an  acceptable  value.  This 
"error  checking"  alsc  applies  to  the  spelling  of  the  names 
cf  the  ships  you  will  be  using.  Your  bywords  should  be 
"relax,  I  can't  hurt  anything." 

With  an  eye  towards  flexibility,  the  program  can  be 
eperated  either  from  the  keyboard  cf  a  computer  terminal  (in 
this  case  a  VT-100/1C2),  through  voice  recognition  equip¬ 
ment,  cr  through  both  simultaneously.  Throughout  this 
User's  Manual,  bott  the  keyboard  and  the  voice  entry 
response  options  will  be  shown  for  each  query. 

The  database  for  this  DSS  in  oriented  to  the  Pacific 
fleet.  The  130  ships  in  the  database  comprise  those  PACFLT 
units  whichcould  be  expected  to  be  assigned  to  a  battle 
group.  While  the  service  force  units  are  included  in  the 
database,  there  are  no  amphibious  ships  included. 

If  you  were  to  group  the  program  capabilities  into  two 
general  categories,  you  would  differentiate  between  these 
portions  which  rely  cn  graphics  software  (Dl-3000)  unigue 
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operations  and  those  that  don't.  in  general,  the  REASONS, 
SENSOR,  and  COHMS (for  the  display  coma  Net  capability  only) 
■odules  utilize  computer  graphics.  If  you  do  not  have  a 
graphics  capability  at  the  position  where  ycu  are  operating, 
then  ycu  cannot  attempt  to  utilize  these  sections  without 
causing  an  ERROR  to  cccur  in  the  computer  operating  system. 
If  this  applies  to  you,  simply  do  not  attempt  to  use  those 
sections. 

This  Oser's  Hanual  has  been  designed  to  give  ycu  an 
exposure  to  all  the  interactions  you  could  expect  to  have 
with  the  system.  In  each  example,  you  will  be  shown  sample 
entries  from  both  the  keyboard  (KB)  and  the  voice  recogni¬ 
tion  (VB)  eguipaent.  The  samples  will  be  prefaced  by  KB  or 
VR,  as  appropriate.  Throughout  the  manual,  when  entering  a 
command  free  the  keyboard,  you  will  be  required  to  depress 
the  CARRIAGE  RETURN  key  (designated  as  <cr>) .  Also,  all 
ccmmands  from  the  keyboard  ROST  be  in  upper  case.  This 
differs  somewhat  frox  the  operations  using  the  voice  recog¬ 
nition  equipment.  There  will  be  some  voice  commands  which 
already  have  incorporated  into  their  output  strings  a 
CARRIAGE  RETURN.  There  will  be  others,  however,  which 
require  that  the  CARRIAGE  RETURN  command  be  input. 
Examples  for  the  commands  from  the  VR  equipment  will  be  very 
explicit,  and  will  show  the  command  "Carriage  Return",  if 
required.  You  can  refer  to  Appendix  A  for  a  detailed 
explanation  of  the  voice  commands  and  applicable  output 
strings. 

There  will  be  occasions  when  the  sample  command  is  shewn 
within  the  text  of  a  corresponding  explanation.  In  these 
cases,  the  commands  will  be  shown  within  quotes.  If  they 
are  keyboard  commands,  DO  NCT  enter  the  quotes  with  the 
command,  simply  enter  the  portion  of  the  example  within  the 
quotes. 


Shile  vc  ace  on  the  topic  o i  the  CABBIAGE  BETUBN  func¬ 
tion,  the  prograa  Hill  occasionally  pause  to  allow  ycu  to 
exaaine  the  infcreaticn  on  the  screen.  In  these  cases, 
thece  will  appear  at  the  bottoe  of  the  screen  the  following 
state lent. 

***  PBESS  CABBIAGE  CONTBOL  TO  -OHTIHOE  *** 

To  cany  out  this  coimand,  jou  would  enter  the  following: 

KB  —  <cr> 

?B  —  "Carriage  Beturn" 

finally,  in  aost  cases,  th9  screen  display  for  the 
gueries  we  will  be  discussing  will  be  shown  in  figures 
adjoining  the  explanation.  There  will  be  soae  occasions 
where  the  inforaation  displayed  in  a  figure  will  not  be  in 
the  exact  fcraat  which  you  wculd  see  on  the  screen.  This  is 
due  tc  the  fact  that  cn  the  screen,  80  columns  of  informa¬ 
tion  can  be  displayed,  whereas  in  the  figures,  only  5U 
columns  cf  information  can  be  shown.  The  contents  of  the 
inforiaticn  in  the  figures  will  be  complete,  however  its 
format  will  be  different.  In  these  cases,  the  reference  to 
the  applicable  figure  will  have  “(adjusted)"  written  after 
the  figure  number.  An  example  of  this  would  be  when  there 
are  twc  large  groups  of  information  displayed  side  by  side 
on  the  screen.  In  most  cases,  the  figure  representing  the 
inforiaticn  would  shew  the  same  information  in  a  single 
columnar  fashion.  This  will  become  more  clear  tc  you  as 
ycu  proceed  through  this  manual,  and  operate  the  system. 
The  next  step  is  to  cet  going  with  the  system. 

B.  INITIATING  THE  P  BCG  BAH  AT  THE  TEBNINAL  STATION 

legging  on  to  a  computer  system  and  running  a  pregram 
are  unigue  to  the  particular  system.  This  Decision  support 


System  Has  developed  on  a  VAX  11/780  computer  system  which 
had  a  RAMTEK  color  graphics  capability  associated  with  the 
computer  operating  system.  The  following  proceduras  are 
unique  tc  this  system.  lou  may  have  to  adapt  them  to  ycur 
cwn  system  as  appropriate.  If  you  are  also  utilizing  the 
ET-600  voice  recognition  equipment,  you  should  lead  the 
voice  tape  into  the  program  tape  reader  at  this  time. 
Additionally,  connect  the  T-60Q/VT- 100/102  and  the  VAX 
11/780  together  using  the  interface  designed  for  this 
purpese  in  the  w ARLAE.  Now  you  are  ready  to  go. 

If  USERNAME  is  not  currently  being  displayed  on  the 
terminal  screen,  you  should  enter  the  following: 

KB  —  <cr> 

VR  —  "Carriage  Return" 

1 .  log in/Pr cgrair  Initiation  from  the  Keyboard 

Row  that  USEFFAME  is  being  displayed,  and  you  are 
operating  from  the  keyboard,  enter  "DECISION  <cr>".  You 
will  new  see  PASSWORD  being  displayed.  (Obtain  the  pass¬ 
word  from  the  WARLAB  staff,  and  make  the  appropriate  entry.) 
This  display  will  end  with  the  symbol  $,  and  you  are  now 
ready  to  run  the  pregram.  Enter  "RUN  DSS  <cr>",  and  you 
will  begin  to  see  the  displays  from  the  Decisicn  Support 
System. 

2.  ^qqip/Prcgra m  Inltiatign  through  Voice  Equipment 

If  you  are  operating  with  the  voice  equipment,  enter 
"LOG  DECISION  ON."  You  will  then  see  administrative  infor¬ 
mation  frem  the  operating  system  on  the  screen,  followed  by 
the  symbol  $.  Now  enter  "RUN  DSS  PROGRAM,"  and  you  will 

begin  tc  see  the  displays  from  the  Decision  Support  System. 
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C.  PB06FAH  DATABASE  IIITIAIIZATIOH 

is  was  discussed  in  Chapter  I  of  this  Decision  Support 
System,  you  have  the  capability  to  work  within  the  system 
and  then  terminate  a  session  without  loosing  the  information 
you  have  developed  about  your  battle  group.  This  is  dene 
through  the  use  of  the  SAVE  module.  Hhen  you  commence  a 
run/sessicn  of  the  system,  you  will  be  presented  with  one  of 
two  series  of  gueries  for  information.  The  one  which  is 
presented  will  depend  on  whether  you  have  stored  a  battle 
group  database  from  a  previous  session.  He  will  lock  at 
both  versions.  He  will  first  examine  the  situation  where 
there  is  a  saved  database  and  then  look  at  one  in  which 
there  is  none. 

1.  tattle  Group  Formed  During  Previous  Session 

If  this  is  net  your  first  session  with  the  battle 
group  database,  then  you  will  be  initially  shewn  the 
existing  composition  of  the  battle  group  in  the  database. 
Figure  3.1  shows  an  example  cf  the  view  you  would  see  and 
reflects  a  five  (5)  ship  battle  group  consisting  of  OSS 
8IHI1Z,  CSS  PAUL  F  FCSTER,  OSS  YORKTOHN,  OSS  MERRILL,  and 
OSS  G0IT8RRC  already  created.  You  will  be  gueried  as  to 
whether  cr  not  you  desire  to  continue  with  this  battle 
group. 


» 
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a.  Desire  to  Retain  the  Battle  Group  w 

If  you  desire  to  retain  the  existing  battle 
group  database,  then  you  would  respond  to  this  query  as 
follows:  § 

KE  —  YES  <cr> 

VE  —  "Affirmative" 


I 


A  EATTLE  GROUP  DATAEASE  HAS  BEER  SAVED  FROM  A  PREVIOUS 
SESSIC8.  BATTLE  GROUP  COMPOSITION  IS  AS  FOLLOWS: 


NIMITZ 

PAUL  F  FOSTER 
YORK  TOWN 
MERRILL 
GUITARRO 

???  WOULD  YOU  LIKE  TO  CONTINUE  WITH  THIS  DATABASE  ??? 
(YES  OR  NO) 

-  -  -  .  » 

figure  3*1  Battle  Group  Already  Formed. 

t.  Does  Not  Desire  to  Retain  the  Battle  Group 

If  you  dc  not  desire  to  retain  the  existing 
battle  group  database,  then  you  would  respond  to  the  query 
as  fellows: 

KB  —  NO  <cr> 

VR  —  "Negativa" 

The  battle  group  database  has  now  been  erased  and  you  will 
receive  the  following  confirmation  on  the  screen. 

THE  DATABASE  HAS  BEEN  DELETED  AND  A  NEW  BATTLE  GROUP  MUST 
NOW  EE  ECILT. 


I 
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c.  Error  in  Making  Response 

Figure  3.2  shows  the  display  you  will  receive  if 
you  inadvertantly  make  a  mistake  in  entering  the  YES/NO 
response.  Should  this  occur,  simply  reenter  the  response. 


I 
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YCOB  BESPONSE  IS  NOT  RECCGNIZEABLE  AS  AN  ACCEPTABLE 
ANSHEB.  PLEASE  ENTER  YES  OR  NO. 


figure  3.2  Error  ia  Making  IBS/NO  Response. 

2.  Pro gran  operation  Based  on  Response 

Now  that  you  have  Bade  the  decision  as  to  whether  or 
net  you  desire  to  retain  a  previously  formed  battle  group, 
the  system  will  do  one  of  two  things  based  on  your  decision. 
If  your  response  was  "Yes,"  the  battle  group  database  will 
te  leaded  into  the  operating  section  of  the  system.  This 
will  be  transparent  to  you  with  the  exception  of  a  possible 
one  second  delay  in  refreshing  the  screen.  If  your 

response  was  "No,"  then  as  was  confirmed  to  you,  the  battle 
group  database  has  been  deleted.  in  either  case,  the  next 
view  that  you  would  see  is  the  same  as  if  you  were  starting 
the  system  without  any  previous  information  being  saved. 
That  will  be  the  topic  of  our  next  section. 

3.  aiiM  af  aiiu  ssaa  QBil2a& 

If  you  are  initially  forming  a  battle  group,  cr  you 
have  already  decided  cn  the  disposition  of  the  saved  battle 
group  database,  then  the  next  query  you  will  receive  will  be 
to  detenine  if  you  desire  to  review  the  Main  Menu  options, 
as  shewn  in  Figure  3.3. 

If  you  desire  to  review  the  options,  enter  the 
following: 

KE  --  YES  <CT> 

?R  —  "Affirmative" 


'  •  'J 

I  « 


???  SCOLD  YOU  LI  KE  TO  BEVIES  THE  WAIN  HENO  OPTIONS  ??? 
(YES/NO) 


Figure  3.3  Review  of  Bais  Menu  Options  Query. 

If  you  DO  NOT  desire  to  review  the  options  enter  the 
following: 


RB  —  NO  <cr> 
VR  —  "Negative" 


I  « 


a.  Error  in  Waking  YES/NO  Response 

If  you  inadvertantly  make  a  mistake  in  entering 
the  YES/NO  response,  you  will  see  the  view  as  shown  in 
Figure  3.2,  on  the  screen.  If  this  occurs,  simply  reenter 
your  response. 

4 .  Pi srlav  of  Main  Menu  Options 

If  your  response  was  to  display  the  Main  Menu 
Options,  then  you  wculd  have  the  display  as  shown  in  Figure 
3.4  (ad jested)  and  Figure  3.5  (adjusted)  displayed  on  the 
screen.  They  are  presented  in  two  segments  as  the  amount  of 
inforeaticn  shown  exceeds  the  capability  imposed  by  the  size 
cf  the  terminal  screen. 


9  i 


9 . li 


I  -Ji 


|  « 


Shen  you  are  ready  to  continue,  enter  the  following 
to  sec  the  remainder  cf  thes  menu.  *  ~ 

KB  —  <cr> 

VR  —  "Carriage  Return" 

I  J 


I  < 


60 


****************************************************** 


* 

* 

* 

* 

* 

* 

* 

*  EUI1D 

* 

* 

* 

*  STATUS 

* 

* 

* 

* 

* 

*  CCMMS 

* 

* 

* 

* 


* 
* 
* 
* 
* 
* 
* 

-  ESTABLISH  A  LOCAL  DATABASE  BY  IDENTIFY-* 

* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 


BATTLE  GROUP  ASSET  MANAGEMENT 
DECISION  SUPEORT  SYSTEM 

MAIN  MENU 


ING  SPECIFIC  BATTLE  GROUP  UNITS  OR 
MAKE  CHANGES  TO  EXISTING  DATABASE  BY 
ADDING  OR  DELETING  A  UNIT 

CALI  OUT,  DISPLAY,  OR  CHANGE  BATTLE 
GROOE  UNIT  ECSITION,  MISSION,  EMBARKED 
COMMANDER,  NUMBERS  OF  UHF/HF  RADIOS. 
AND  CHANGE  IN  ONBOARD  SENSORS  OF  WEA¬ 
PONS  SYSTEMS 


ESTABLISH  PRIORITT'SED  NETS  AND  UNIT/ 
WARFARE  CDS  NET  PARTICIPATION,  GRAPHIC-* 
ALLY  DISPLAY  NET  OR  MSG  PATH  * 

* 

(MENU  CONTINUED)  * 


***  PRESS  CARRIAGE  RETURN  TO  CONTINUE  *** 


Figure  3.4  Bain  Beau  Options. 


when  you  are  ready  to  continue,  enter  the  CARRIAGE 
RETURN  ccanand  as  described  above. 

5.  Selection  pf  Main  M enu  Options 

At  this  point,  you  will  be  queried  as  tc  which 
cpticn  ycu  desire  to  utilize.  This  query  is  shown  in  Figure 
3.6. 

There  is  one  caution  which  you  should  be  aware  of 
before  ycu  make  your  selection.  If  the  battle  group  data¬ 
base  eiists  and  you  have  retained  it,  then  you  are  free  to 
select  any  of  the  Main  Menu  options  shown  in  Figure  3.6. 
However,  if  this  is  the  first  session  you  are  having  with 
the  system,  and/or  the  battle  group  has  net,  as  yet,  been 
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(BAIN  MENU  CCSTI.)  * 

SENSCB  -  GRAEBICALLY  DISPLAY  UNIT/FORCE  SENSCB  * 

COVEBAGE  ABEAS  AND  EXPERIMENT  WITB  UNIT* 
POS IIION/S ENSOR  COVERAGE  AREA  INTERFLAY* 

* 

WEAPONS -  GRAPHICALLY  DISPLAY  UNIT/FORCE  WEAPONS  * 

COVEBAGE  AREAS  AND  EXPERIMENT  WITH  UNIT* 
POSITION/W  EAPCNS  SYSTEM  COVERAGE  AREA  * 
INTERPLAY.  * 

* 

IATAEASE - DISPLAY  THE  SHIPS  IN  THE  DATABASE  BY  * 

TYPE 


SAVE  -  STORE  CURRENT  BATTLE  GROUP  DATABASE  IN  * 

A  FILE  AND  THEN  STOP  THE  PROGRAM  * 

* 

STCP  -  STOPS  THE  PROGRAM  WITHOUT  SAVING  THE  * 

DATA  INTO  A  FILE  * 


************************  ****************************** 

***  PRESS  CARRIAGE  BETURN  TO  CONTINUE  *** 


Figure  3. 5  Main  Menu  Options  (conti) . 


,,  1  ... ....  . . . 

?  SELECT  ONE  OF 

TEE  FOLLOWING: 

- » 

BUILD 

STATUS 

COMMS 

WEAPONS 

SAVE 

SENSOR 

STOP 

DATABASE 

IF  YOU  DESIRE  TO 
"MENU" 

REVIEW  THE 

MAIN 

MENU  OPTIONS  ENTER 

figure  3.6  Selection  of  Main  Menu  Option. 


foraed,  ycur  selections  are  restricted  to  either  the 
DATABASE  or  BUILD  options.  The  reason  for  this  is  that  all 
ether  systea  aodules  require  scae  or  all  cf  the  inferaation 
contained  in  the  database,  which  either  aust  exist  or 
initially  be  established  in  the  BUILD  aodule.  Should  you 
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accidentally  attempt  to  enter  ether  than  the  DATAEASE  or 
BUILD  icdules  in  this  case,  you  will  receive  the  following 
warning  and  will  be  placed  in  the  BOILO  aodul9. 

THERE  ASE  8C  ONUS  IN  THE  B  ATT  IE  GROUP  DATAEASE  AND  TOO  MOST 
IIRST  E03LE  THE  BATTIE  GROOP.  PLEASE  ANSWER  THE  FOLLOWING 
COESTICNS. 

For  a  more  detailed  explanation  of  the  operations  of 
the  various  nodules  in  the  systea,  refer  to  the  appropriate 
section  on  the  operations  of  that  nodule.  For  example, 
inforaation  on  the  DATABASE  nodule  would  be  found  in  the 
section  entitled  DATABASE  nodule  Operations.  If  you  are 
initially  feraing  the  battle  group,  the  the  following  short 
description  of  the  functions  of  the  BUILD  module  will  be  of 
some  value. 

a.  BUILD  Module  Functions  During  Battle  Group 
Initialisation 

When  you  are  forming  the  battle  group,  the  BUILD 
nodule  will  orchestrate  the  collection  of  data  as  follows: 

•  Number  of  units  in  your  battle  group 

•  Naaes  of  the  units  in  your  battle  group 

•  Name  of  the  battle  group  unit  to  be  designated  as  "ZZ" 
(for  the  purposes  of  this  Decision  Support  System,  a 
tattle  group  unit  MUST  be  at  nZZu) 

•  Type  of  coordinate  system  used  for  stationing  assign¬ 
ments  (POLAR  or  CARTESIAN) 

•  Positions  of  all  units  in  the  battle  group 

•  Ccapcsite  Warfare  Commander  (CWC)  Organization 

•  Helicopter  enbar cation  status  for  HELO  capable  units 
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Once  you  have  identified  the  names  of  the  units 
in  your  tattle  group,  intonation  concerning  the  onboard 
senscrs,  weapons  systems,  and  administrative  information 
(e.g.  Group  Commander),  unigue  to  each  unit,  is  automati¬ 
cally  obtained  from  a  master  database.  This  database 
contains  in  excess  of  130  ships  from  which  to  choose. 
Should  a  unit  in  your  battle  group  net  be  in  this  master 
database,  you  will  be  asked  to  provide  the  necessary  infor¬ 
mation  manually  through  the  use  of  capability  menus 
(discussed  in  BUILD  Module  Operations)  provided  on  the 
terminal  screen.  Once  this  manual  operation  is  complete, 
the  unit  will  be  permanently  placed  in  the  master  database 
so  that  in  the  future,  manual  information  insertion  will  not 
be  necessary  for  that  unit. 

6.  Bis  take  in  Requesting  a  Bain  Menu  Option 

To  protect  ycu  should  a  mistake  be  made,  there  are 
parts  of  this  system  which  will  check  your  entries  and  if 
they  are  incorrect,  advise  you  of  such  and  allow  you  to  make 
a  correct  entry.  At  example  is  contained  in  the  following 
secticn. 

a.  Hispelling  of  a  Main  Menu  Option 

Should  ycu  accidentally  mispell  a  request  for  a 
Bain  flenu  Option,  you  will  receive  a  warning  as  shewn  in 
figure  3.7. 

To  correct  this  mistake,  simply  reenter  the 
desired  option.  Some  examples  are  shown  below. 

KB  —  BUILD  <cr>  or  WEAEONS  <cr>  or  SENSOR  <cr> 

—  "Builc  Module"  or  "Weapons  Module" 
cr  "Sensor  Module" 


YOUR  SELECTION.  IS  ENTERED.  DOES  NOT  CORRESPOND  TC  THE 
CHOICES  AVAILABLE  IN  THE  MAIN  IIENU.  PLEASE  ENTER  ONE 
OF  THE  FOLLOWING: 


BUILD  STATUS  COHNS  WEAPONS 

SAVE  SE  ESCB  STOP  DATABASE 

HENU 


Figure  3.7  lisp elling  of  a  Bain  Henu  Option. 

0.  Bill  NODULE  OPER ATI01S 

The  Hain  module,  as  an  entity,  may  be  transparent  to 
you.  It  has  been  designed  as  a  controller  that  organizes 
the  flow  cf  your  coamands/desires  between  the  other  modules. 
Its  principle  function  is  tc  provide  you  a  focal  point  from 
which  you  can  easily  icve  to  the  othar  modules.  You  have 
already  seen  an  example  of  this  as  you  initialized  ycur 
battle  group  database  using  the  DATABASE  and/or  BUILD 
modules. 

As  you  move  through  the  modules,  when  you  elect  to 
finish  with  that  particular  module,  you  will  always  be 
returned  tc  the  Bain  module.  This  is  signified  by  the  guery 
shown  in  Figure  3.3.  The  descriptions  of  each  module,  as 
shown  in  Figure  3.4  and  Figure  3.5,  are  self  explanatory. 
The  remainder  of  this  User's  Manual  is  organized  into 
sections  which  address  the  operations  of  each  module.  In 
every  case,  you  will  be  walked  through  a  session  which  exer¬ 
cises  the  capabilities  of  that  module,  as  well  as  be  shewn 
seme  cf  the-possible  pitfalls  or  problems  you  may  encounter. 
There  are  two  modules  that  require  some  emphasis  at  this 
point,  as  they  will  terminate  a  session  in  distinctly 
different  fashions.  These  are  the  STOP  and  the  SAVE 
modules.  They  will  be  discussed  next. 
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I.  "STOP"  HODOLB  BBC  "SAVE"  MODULE  OPERATIONS 


These  two  modules  are  discussed  together,  as  they  both 
result  in  the  temination  of  a  session  in  the  Decision 
Support  System.  The  SAVE  module,  however,  will  first  file 
all  the  tattle  croup  information  that  you  have  developed 
before  termination  occurs.  This  contrasts  to  the  func¬ 
tioning  of  the  STOP  module  which  terminates  a  session 
without  filing  any  of  the  developed  information. 
Terminating  a  session  with  the  STOP  module  will  require  you 
to  fctm  a  new  battle  group  at  the  beginning  of  your  next 
system  session.  Let's  briefly  expand  on  the  operations  of 
these  twc  modules. 

1  •  *A  WE  Module  Ccerations 

The  SAVE  module  has  been  designed  to  store  the  data¬ 
base  fcr  your  battle  croup  when  you  desire  to  terminate  ycur 
session.  It  is  invoked  from  the  query  shown  in  Figure  3.6, 
as  fellows: 


KE  —  SAVE  <cr> 

VB  —  "Save  Module" 

When  you  invoke  this  capability  of  the  DSS,  the  ship 
names,  capabilities,  positions,  administrative  data,  etc., 
which  you  have  developed  for  ycur  battle  group,  as  well  as 
the  CSC  Organization,  will  all  be  stored  fcr  future  use. 
Having  terminated  a  session  with  this  module,  when  you  rein¬ 
itiate  a  DSS  session,  you  will  be  initially  be  presented 
with  the  information  shown  in  Figure  3.1. 

Session  termination  on  the  VAX  11/780  will  be  marked 
by  the  statement  FCBTRAN  STOP  followed  by  the  symbol  $ 
appearing  on  the  screen.  when  this  occurs,  you  can  termi¬ 
nate  your  CSS  session  with  the  following  command. 


66 


\  . 


FE  —  ICGO  <cr> 

VB  —  "Terminate" 

You  axe  row  finished,  and  can  turn  the  terminal  and  graphics 
(if  applicable)  off. 

2.  §TQE  Module  Operations 

The  functioning  of  the  STOP  module  is  straigfctfo- 
ward.  It  will  terminate  your  session  without  saving/ 
storing  any  of  the  information  which  you  have  developed.  It 
is  invoked  from  the  guery  shown  in  Figure  3.6,  as  follows: 

KE  —  STOP  <CT> 

VB  —  "Step  Module" 

If  you  have  no  future  requirement  for  the  data  with 
which  you  have  teen  working,  then  this  is  the  capability 
that  you  should  use  to  terminate  your  DSS  session.  Any 
information  previously  stored  will  be  deleted  when  the  STOP 
module  is  irvoked. 

The  pragmatics  of  a  session  termination  when  using 
the  STOP  module  on  the  VAX  11/780  are  identical  to  these 
described  in  the  section  on  the  SAVE  module  Operations. 

3  •  Program  Initiated  SAVE  Function 

There  is  notiing  more  frustrating  to  the  experienced 
computer  user,  or  intimidating  to  the  inexperienced  user 
than  to  have  the  program  "bomb,"  for  no  explainable  reason. 
The  reasons  for  this  are,  of  course,  more  often  than  not, 
explainable.  However,  that  doesn't  restore  the  sometimes 

hours  cf  work  which  may  have  lead  up  to  the  incident.  That 
may  be  hours  of  work  which  were  lost. 

In  an  effort  to  alleviate  such  anxiety,  and  protect 
against  a  loss  of  information,  the  Decision  Support  System 
has  teen  designed  to  perform  a  one-time  automatic  SAVE  of 
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the  information  which  you  have  entered.  This  will  occur  at 
the  completion  cf  ycur  first  establishment  of  the  battle 
group  database  in  the  BUILD  module.  You  are  not  required 
to  perform  any  keystroke  cr  voice  command  to  effect  this 
SAVE .  In  fact,  with  the  exception  of  a  possible  1-2  second 
delay  in  refreshing  the  screen,  it  will  be  transparent  to 
you.  This  capability  is  identical  to  that  which  ycu  would 
use  by  invoking  the  SAVE  module,  with  the  exception  that  the 
session  will  EOT  be  terminated.  In  this  manner,  should  a 
power  failure  or  fluctuation  cause  the  program  to  "bcrnt," 
you  will  net  loose  the  work  ycu  have  done.  When  you  reini¬ 
tiate  the  program,  the  information  will  appear  as  shown  in 
Figure  3.1,  just  as  if  YOU  had  saved  it.  Invoking  the  STOP 
Nodule  will  erase  this  information  before  terminating  ycur 
CSS  session. 

!•  E1IAEASE  NODULE  CSEBATICHS 

There  could  be  two  situations  in  which  you  may  find 
yourself  when  using  this  decision  support  system.  The 
first,  and  most  predeminant,  instance  will  be  that  you  have 
a  battle  group  formed  and  you  enter  the  names  of  the  units 
in  that  kattle  group  into  the  system.  Transparent  to  you, 
the  program  will  take  those  names  and  extract  from  a  master 
database,  the  capabilities,  administrative  data,  etc., 
attributable  to  those  particular  units.  As  was  mentioned 
earlier,  there  are  some  130  ships  in  the  master  database. 
So,  ycu  can  see  that  all  ships  in  the  Navy  are  not  there. 
Insertion  cf  the  name  of  a  unit  which  is  not  in  the  database 
would  require  you  to  enter  its  database  of  information  manu¬ 
ally.  If  you  would  like  to  confirm  that  one  of  your  battle 
group's  units  is  in  the  master  database  prior  to  inserting 
its  came  in  the  BUI LC  module,  you  could  invoke  the  DATABASE 
module  and  access  tte  particular  ship  type  of  the  unit  for 
which  ycu  are  looking. 
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The  second  situation  you  may  find  yourself  in  is  that 
you  are  experimenting  with  theoretical  battle  group  composi¬ 
tions,  and  would  like  to  select  fron  the  list  of  available 
units  the  ships  for  your  battle  group.  Again,  invoking  the 
EATAEASE  acdule  will  allow  you  to  view  all  of  the  units  in 
the  aaster  database,  in  groupings  of  ship  type,  as  you 
desire. 

1 .  Invoking  t^e  EATABASE  Module 

Ehen  presentee  with  the  guery  shown  in  Figure  3.6, 
the  EATAEASE  aodule  can  be  inveked  as  follows: 

KB  —  DATABASE  <cr> 

?R  —  "Database  Module" 

This  entry  will  move  you  from  the  Main  module  into 
the  EATAEASE  module  and  you  will  be  presented  with  the  guery 
shown  in  Figure  3.8  (adjusted)  . 


2.  .Selecting  a.  Shi£  Tj£e  O£iioa 

Figure  3.8  provides  the  menu  for  selection  of  the 
available  ship  types  in  the  master  database.  To  display 
the  names  and  hull  nuxbers  cf  the  units  in  a  particular  ship 
type  grouping,  simply  enter  the  number  corresponding  to  the 
ship  type  you  desire.  An  example  of  this  response  is  shewn 
below . 


VB 


KB  —  1  <cr>  or 

1 3  <cr> 

"One"  "Carriage  Return"  or  "One"  "Three" 
"Carriage  Return" 
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***************************  5*  *******************  ******* 


*  BATTIE  GBOUE  ASSZT  MANAGEMENT  * 

*  DECISION  SUPPORT  SYSTEM  * 

*  * 

*  *  DATABASE  MODULE  *  * 

*  * 


****************************************************** 

IBIS  MODULE  ALLOWS  YOU  TC  DISPLAY  THE  UNITS  IN  THE 
MASTER  DATABASE  AS  CATEGORIZED  BELOW.  SELECT  THE  NUM- 
BEB  CCBBESPONDI NG  10  THE  SHIP  TYPE  YOU  DESIRE. 

1  -  SUBMARINES  (SSN) 

2  -  AIRCRAFT  CARRIERS  (CV/CVN) 

3  -  GUIDED  MISSILE  CRUISERS  (CG/CGN) 

4  -  DESTRCYERS  (DD) 

5  -  GUIDED  MISSILE  DESTROYERS  (DEG) 

6  -  FRIGATES  (FF) 

7  -  GUIDED  MISSILE  FRIGATES  (FFG) 

8  -  BATTLESHIPS  (BB) 

9  -  REPLENISHMENT  OILERS  (AOR) 

10  -  FAST  CCMBAT  SUPPORT  SHIPS  (AOE) 

11  -  COMBAT  STORES  SHIPS  (AFS) 

12  -  AMMUNITION  SHIPS  (AE) 

13  -  OILERS  (AO) 


Figure  3.8  DATABASE  Module  Selections. 

In  this  example,  the  ship  type  SUBMARINES  or  OILERS 
would  he  selected.  Figure  3.9  is  an  example  of  what  you 
would  see  having  selected  the  ship  type  SUBMARINES  (SSN). 


PEFMIT 
LCS  ANGELES 
LA  JOLLA 


*  SUBMARINES  * 

SSN594  GUITARRO 

SSN688  INDIANAPOLIS 

SSN701 


SSN665 

SSN697 


***  PEESS  RETURN  TO  CONTINUE  *** 


Figure  3.9  SUEBARIHES  in  the  Master  Database. 
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If  your  selection  had  been  in  the  latter  example 
above,  ycu  would  be  selecting  the  OZLBB  (&0)  ship  type,  and 
figure  3.10  shows  the  view  you  would  get  on  the  screen. 


*  OILEPS  * 

CIMABRON  AC177  WILLAMETTE  AO180 

E LATTE  AC  186 

***  PBESS  RETURN  TO  CONTINUE  *** 


figure  3.10  OILERS  in  the  Master  Database. 

When  you  are  through  exaaining  the  ships  in  the  ship 
type  grouping  you  have  selected,  enter  the  following 
commands: 

KB  —  <cr> 

VR  —  "Carriage  Beturn" 

To  allow  you  the  opportunity  to  view  another  ship 
type,  ycu  will  receive  the  following  query. 

???  WOULD  YOU  LIKE  TO  SEE  AN0TH3B  SHIP  TYPE  ??? 
(YES/NO) 

Ycui  response  to  this  query  would  be  the  following, 
as  applicable 

KB  —  YES  <cr>  or  NO  <cr> 

VB  —  "Affirmative"  or  "Negative" 

If  your  response  is  net  to  see  another  ship  type, 
then  ycu  will  be  returned  to  the  Main  module.  If  you 


desire  tc  see  another  ship  type,  you  will  be  presented  with 
the  EATAEASE  nodule  senu  (Figure  3.8). 

Should  you  inadvertantly  make  a  mistake  entering 
your  YES/NO  response,  you  will  be  presented  with  the 
following. 

PHASE  ENTEB  YES  OB  NO 

At  that  point,  simply  reenter  your  YES/NO  response. 

a.  Error  in  Selecting  Ship  Type  From  Menu 

Should  you  accidentally  make  an  incorrect  entry 
while  making  your  ship  type  selection,  you  will  be  presented 
with  the  following  on  the  screen. 

YOOH  SELECTION  DOES  NOT  CORBESPOND  TO  THE  MENU  OPTIONS. 
YOU  HILL  HAVE  TO  REENTEB. 

♦**  pfiESS  RETURN  TO  CONTINUE  *** 

To  continue,  make  the  CARRIAGE  RETURN  command  as 
described  above,  and  you  will  be  returned  to  the  DATABASE 
module  menu. 

6.  BUILT  MODULE  OPERATIONS 

Hbile  the  MAIN  module  is  the  hub  of  activity  between  the 
modules  of  tks  system,  the  BUILD  module  develops  the  founaa- 
tion  upon  which  the  entire  system  will  operate.  within  the 
BUILD  module,  the  composition  of  the  battle  group  in  deter¬ 
mined,  unit  positions  assigned,  and  the  Composite  Warfare 
Commander  (CWC)  organization  managed.  There  are  two 
differentiable  segments  to  the  BUILD  module.  They  are 
oriented  around  whether  a  battle  group  database  (previously 
specified  by  the  user)  already  exists. 

When  there  is  no  battle  group  formed,  you  will  first 
work  within  this  module  to  identify  the  names  of  the  battle 
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group  units,  their  positions  and  helicopter  embarcation 
status.  Additionally,  along  the  way,  you  will  identify  a 
unit  which  will  function  as  "ZZ"  (Remember  that  this  system 
requires  a  battle  group  unit  be  at  "ZZ."),  specify  a  coordi¬ 
nate  systea  to  be  utilized,  and  identify  the  organizations 
which  will  function  as  warfare  coaaanders.  As  was 
■enticned  earlier,  when  you  specify  a  unit's  name,  its  data¬ 
base  is  autoaat ically  obtained  unless  zhe  ship  does  not 
reside  in  the  aaster  database,  in  which  case  you  would  manu¬ 
ally  enter  that  data. 

Cnee  the  battle  group  has  been  formed,  you  would  use  the 
EUILD  module  to  INSEBT  or  DELETE  a  unit,  or  to  REBUILD  the 
entire  battle  group  databasa.  whan  you  exercise  the  INSERT 
capability,  you  would  go  through  the  same  sequence  of 
queries  regarding  the  unit  to  be  inserted  as  you  did  when 
initially  forming  the  battle  group.  When  you  exercise  the 
DELETE  capability,  as  the  name  implies,  you  would  be 
removing  the  information  for  the  specified  unit  from  the 
tattle  group  database.  The  REBUILD  capability  allows  you 
to  construct  a  completely  new  battle  group  database. 

In  the  following  sections,  we  will  move  through  the 
BUILD  module  and  demonstrate  the  interactions  you  can  antic¬ 
ipate  having.  The  BUILD  module  is  invoked  from  the  query 
shown  in  Figure  3.6,  as  follows. 

KB  —  EUILD  <cr> 

VR  —  "Build  Module" 

Be  will  rew  go  through  the  operations  of  -his  module. 

1-  ililiaiil  LQIJiaa  a  Battle  G^oup 

Fox  the  purposes  of  our  example,  we  will  operate 
with  a  three  (3)  ship  battle  group  consisting  of  USS  CARL 
VINSON  (CVN-70)  ,  USS  PAUL  F  FOSTER  (DD-964)  ,  and  USS 
CALIFORNIA  (CGN-36)  (a  unit  net  in  the  master  database). 


73 


The  first  view  which  you  will  be  shown  is  an  explanation  of 
the  functions  of  the  eodule,  and  is  shown  in  Figure  3.11 
(adjusted).  This  7iew  reiterates  much  of  what  we  have 
already  discussed  abcut  the  BUILD  nodule. 


BATTLE  GROUE  ASSET  MANAGEMENT 
DECISION  SUPPORT  SYSTEM 

BUILD  MODULE 

THIS  MODULE  BILL  ALLOW  YOU  10  BUILD  A  DATABASE  OF  THE 
CAPABILITIES  OF  THE  UNITS  IN  YOUfi  BATTLE  GROUP.  THESE 
CAPABILITIES  BILL  INCLUDE  ALL  SENSOR  AND  WEAPONS  SYS¬ 
TEMS  CNBCARD ,  AS  SELL  AS  NUMBERS  OF  UHF/HF  RADIOS  ON¬ 
BOARD.  THIS  DATA  BAS  BEEN  COMPILED  FOR  ALL  PACIFIC 
FLEET  UNITS.  YOU  WILL  BE  ASKED  TO  PROVIDE  THE  NAME  OF 
EACH  UNIT,  AND  THE  COMPUTER  NILL  LOCATE  THE  REQUIRED 
DATA  FOB  THAT  UNIT  AUTOMATICALLY.  SHOULD  A  UNIT  NOT 
BE  IN  THIS  MASTER  DATABASE,  YOU  HILL  BE  SO  INFORMED 
AND  THEN  YOU  HILL  EE  ASKED  TC  PROVIDE  THE  NECESSARY 
INFORMATION  IN  A  "PROMPT /AN SWEB"  FORMAT.  YOU  HILL  NCH 
BE  ASKED  FOR  THE  FUMBER  CF  UNITS  IN  YOUR  BATTLE  GROUP, 
AND  TEEN  THE  NAME  OF  EACH  UNIT.  PLEASE  ANSWER  THE 
QUESTIONS  AS  THEY  APPEAR. 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.11  BUILD  Module  Discussion. 


ihen  you  are  ready  to  ccntinue,  you  would  enter  the 
following: 

KB  —  <cr> 

VR  —  "Carriage  Return" 


The  next  guery  you  will  receive  is  for  the  number  of  ships 
in  your  battle  group. 


a.  Establishing  the  Number  of  Ships  in  Battle  Grcap 

This  will  be  the  only  time  you  will  be  asked  for 
the  total  number  of  ships  in  your  battle  group.  As  you 
operate  the  systea,  once  this  value  has  been  initially 
entered,  it  will  be  automatically  kept  current  by  the 
systea.  the  guery  for  the  number  of  ships  in  the  battle 
group  is  shewn  in  Figure  3.  12  (adjusted)  . 


???  BCH  BANT  SURFACE  COMBATANTS,  CARRIER  (S)  ,  SUBMAR¬ 
INES)  ARE  IN  YOUR  BATTLE  GROUP  ??? 

(ENTER  UP  TO  A  MAXIMUM  OF  25  SHIPS) 


Figure  3, 12  Query  —  Number  of  Ships  in  Battle  Group. 


As  the  guery  shows,  the  range  fer  the  required  input  is  1  - 
25  ships.  Since  cur  sample  battle  group  has  three  (3) 
ships,  we  would  enter  the  following. 

KB  --  3  <cr> 

V R  --  "Three"  "Carriage  Return" 

If  you  had  ten  (10)  ships  in  your  battle  group,  your  entry 
would  lock  like  this. 

KE  —  10  <cr> 

VR  —  "One"  "Zero"  "Carriage  Return" 

If  you  inadvertantly  make  a  mistake  in  making  this  entry, 
you  would  see  the  following  on  the  screen. 

THERE  HAS  EEEN  AN  ERROR  IN  INPUTTING  THE  NUMBER  ON  UNITS  IN 
YOUR  EATTLE  GROUP.  YOU  WILL  HAVE  TO  REENTER  THE  NUMEER. 
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***  PRESS  RETURN  TO  CONTINUE  *** 


Rhen  ycu  are  ready  tc  continue,  and  reenter  your  number  of 
ships,  enter  "RETURN ,"as  described  above,  and  you  will  again 
be  given  the  query  shewn  in  Figure  3.12. 

After  you  have  successfully  entered  the  number 
cf  ships  in  your  battle  group,  you  will  be  given  a  confirma¬ 
tion  cf  jour  entry,  as  shown  in  Figure  3.13.  The  statement 
would  shew  the  number  of  ships  you  entered,  and  ash  ycu  to 
ccnfire  that  the  number  is  correct.  In  our  example,  the 
number  of  ships  entered  was  three  (3)  . 


1EEBE  IS/ABE  3  UNIT  (S)  IN  TOUR  BATTLE  GROUP. 

???  IS  THIS  CORRECT  (YES/NO)  ??? 

■  . . . .... . . . . . . . .  .  .... . j 


Figure  3. 13  Eattle  Group  Size  Confirmation. 


You  should  acknowledge  the  confirmation  with  the  following 
response,  as  appropriate. 

KB  —  YES  <cr  >  or  NO  <cr> 

YB  —  "Affirmative"  or  "Negative" 

Should  ycu  take  an  error  entering  your  YES/NO  response,  you 
will  see  the  following  on  the  screen. 

PLEASE  ENTER  YES  OR  NO 

Simply  reenter  your  YES/NO  response  as  shown  above.  Should 
the  number  shown  in  the  confirmation  statement  be  incorrect, 
you  will  again  be  given  the  query  shown  in  Figure  3.12,  and 
the  sequence  of  events  described  above  will  be  repeated. 


t.  Ship  Name  Entry 


Once  you  have  identified  the  number  of  ships  in 
your  tattle  group,  the  next  step  will  be  to  enter  their 
names.  Following  your  confirmation  that  the  number  of 
ships  in  the  battle  group  is  correct,  the  explanation  shewn 
in  Figure  3.14  (adjusted)  will  be  displayed. 


you  NHL  NOW  BE  ASKED  TO  ENTER  THE  NAMES  OF  THE  UNITS 
IN  YOUR  EATTLE  GROUP.  A  PROMPT  "SHIP  NAME"  WILL  AP¬ 
PEAR  AFTER  WHICH  ECU  SHOULD  ENTER  THE  NAME  OF  A  UNIT. 
REFER  TO  YOUR  USER'S  MANUAL  UNDER  THE  "SHIP  NAME"  LIS¬ 
TINGS  FOR  THE  FORMATS  OF  THE  KEYBOARD  OR  VOICE  ENTRIES 
FOR  AVAILABLE  SHIPS.  FOR  KEYBOARD  ENTRIES,  NAMES  ARE 
LIMITED  TO  19  CHARACTERS  WITHOUT  ANY  COMMAS  OR  PERI¬ 
ODS.  SPACES  BETWEEN  WORDS  COUNT  AS  CHARACTERS.  IF 
TEE  NAME  OF  THE  BATTLE  GROUP  UNIT  DOES  NOT  APPEAR  IN 
IHE  USER'S  MANUAL,  THEN  KEYECARD  ENTRY  WILL  BE  RE¬ 
QUIRED,  AND  VOICE  INPUT  HILL  NOT  WORK. 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.14  Skip  Name  Entry  Explanation. 


When  ycu  are  ready  tc  continue  and  enter  the  names  of  the 
ships  in  ycur  battle  group,  enter  "RETURN,"  as  described 
earlier,  and  you  will  receive  a  "SHIP  NAME  ?"  prompt. 

You  will  receive  this  prompt  a  number  of  times 
which  corresponds  to  the  number  of  ships  you  indicated  were 
in  yeer  battle  group.  You  should  note  that  if  you  are 
entering  the  information  from  the  keyboard,  you  are  limited 
to  nineteen  (19)  characters  for  a  ship's  name,  including 
spaces.  The  length  cf  the  names  of  the  ships  ycu  can  enter 
ty  vcice  have  already  been  matched  to  this  requirement. 
Also  ncte  that  if  the  name  of  a  ship  in  your  battle  group  is 
not  in  the  master  database  (as  you  could  confirm  in  the 
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DATABASE  module  discussed  earlier) ,  voice  entry  is  rot 
possible.  In  this  situation,  the  naote  of  the  ship  would 
base  tc  be  entered  frca  the  keyboard.  If  you  did  nor  check 
the  naaes  cf  your  ships  in  the  DATABASE  module,  you  can 
ccnfira  the  names  in  Appendix  A.  If  the  name  of  a  ship  is 
shown  in  Appendix  A,  then  it  will  be  in  the  master  database. 

For  our  example  battle  group,  the  prompts  and 
applicable  responses  wculd  be  as  follows: 

SHIP  BAM  I  ? 

KB  —  VINSON  <cr>  or  CARL  VINSON  <cr> 

V R  —  "VINSON"  cr  "CARL  VINSON" 

SHIP  KAMI  ? 

KB  —  FOSTER  <cr>  or  PAUL  F  FOSTER  <cr> 

VR  —  "FOSTER"  cr  "PAUL  F  FOSTER" 

SHIP  SAME  ? 

KB  —  CALIFORNIA  <cr> 

VR  —  (not  possible  as  USS  CALIFORNIA  is  not  in  the 
master  database) 

Should  ycu  make  an  error  in  entering  the  name  of 
a  ship,  you  will  see  the  following  on  the  screen. 
Usually,  the  only  mistake  you  can  make  is  to  enter  a  name 
longer  than  nineteen  (19)  characters. 

10 UR  INPUT  SAS  NOT  ACCEPTED  BY  THE  COMPUTER.  YOU  RILL  HAVE 
TO  REENTER  THE  SHIP'S  NAME. 

***  PRESS  RETURN  TO  CONTINUE  *** 

Rhen  ycu  are  ready,  you  continue  as  described  earlier,  and 
the  "SHIP  NAME  ?"  prompt  will  appear.  Ycu  then  reenter 
the  naae  of  the  ship. 


Now  that  you  have  entered  the  names  of  the  ships 
in  your  iattle  group,  you  will  be  shown  the  composition  of 
the  tattle  group  that  you  have  entered  into  the  system. 
This  confirmation  check  is  very  important.  The  naster 
database  is  keyed  to  the  names  of  the  ships,  and  if  the 
spelling  of  the  names  is  not  exact,  then  the  database  will 
treat  the  name  as  if  it  were  not  there,  and  the  user  will  be 
prompted  to  build  the  database  entries  for  that  unit  as 
explained  later.  The  system  has  been  programmed  to  recog¬ 
nize  seme  short  form  names  of  ships  (e.g.  FOSTER  for  PAUL  F 
FCSTEB ,  ox  VI NS CM  for  CARL  VINSON),  but  you  can  never  go 
wrong  by  using  the  full  ship  name.  Always  be  sure  that  you 
include  spaces  where  they  would  be  appropriate.  Figure 
3.15  (adjusted)  shows  the  composition  of  our  example  battle 
group  fox  our  confiriation. 


HEBE  IS  A  LIST  OF  THE  SHIPS  TOO  HAVE  ENTERED  AS  YOOR 
EATTLI  GROUP.  PLEASE  CHECK  THE  LIST  FOR  ACCURACY  AND 
SPELLING . 


1  CARI  VINSON 
3  CALIFORNIA 


2  PAUL  F  FOSTER 


PLEASE  ENSUBE  THAT  THE  AEOVE  NAMES  ARE  CORRECTLY 
SPELLED.  IF  THEY  ARE.  PRESS  CARRIAGE  RETURN,  OTHER- 
»ISE,  ENTER  THE  NUMBER  OF  AN  INCORRECT  ENTRY  AND  EN¬ 
TER  TEE  CORRECT  SPELLING  AFTER  THE  ’'SHIP  NAME  ?" 


TER  TEE 
PROMPT. 


Figure  3. 15  Battle  Group  Name  Listing. 


As  is  directed  in  Figure  3.15,  if  the  entries 
are  correct,  enter  "RETURN,"  (as  described  earlier),  cr  if 
not,  the  number  corresponding  to  the  incorrect  ship  name. 


■v  . 


Is  shewn  in  this  case,  the  list  is  correct,  and  we  should 
enter  EITUBN.  As  an  exaaple,  however,  let  us  assume  that 
CABL  VINSON  was  accidentally  spelled  CABL  VINSAN.  Since 
this  is  incorrect,  ycu  would  enter  the  following. 

KB  —  1  <cr> 

VB  --  "One"  "Carriage  Return" 

You  would  new  sec  the  view  shown  in  Figure  3.16. 


???  BEAT  IS  THE  CCBBECT  INTBY  FOB  CABL  VINSAN  ??? 


Figure  3.  16  Correction  to  Ship  Naae. 


Notice  that  Figure  3. 16  shows  the  incorrect 
spelling  fer  the  ship.  You  would  now  enter  the  correct 
spelling  for  the  VINSCN  (again,  subject  to  the  nineteen  (19) 
character  limit  if  froa  the  keyboard)  ,  as  shown  in  the 
following  exaaple. 

KB  —  CABL  VINSON  <cr> 

VB  —  "CABL  VINSON" 

once  the  correction  to  the  ship  name  has  been 
■ade,  ycu  will  again  be  shown  the  view  in  Figure  3.15  to 
confirm  the  names  cf  the  battle  group  units.  For  the 
purposes  cf  our  exaaple,  we  will  assume  that  it  is  now 
correct,  and  you  should  enter  "BETOBN ,"  (as  described 
earlier) . 

Should  ycu  make  an  error  in  entering  a  CARRIAGE 
BETOBN  or  the  number  of  the  ship  that  is  incorrectly 
spelled,  ycu  would  see  the  following  on  the  screen,  after 
which  ycu  can  aake  the  correct  entry. 
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r HESS  CARRIAGE  RETURN  IF  THE  LIST  IS  CORRECT,  OR  IF  SOT,  THE 
APPRCIRI 111  TWO  DIGIT  SOMBER 

Since  the  listing  was  correct,  and  you  entered 
CARRIAGE  RETURN,  you  will  new  see  an  explanation  of  the 
operations  of  the  system  with  respect  to  the  units  in  your 
battle  group.  This  information  is  shown  in  Figure  3. 17. 
The  display  of  this  view  also  signifies  that  the  master 
database  is  being  searched  for  your  units  and  their  capabil¬ 
ities  are  being  filed  in  a  battle  group  database.  The 
units  not  in  the  naster  database  will  be  ’’flagged”  -for 
manual  insertion  of  their  capabilities  information. 


THE  EATAEASE  IS  BEING  SEARCH  TO  ASSEMBLE  THE  INFORMA¬ 
TION  FCR  YOUR  BATTLE  GROUP.  PLEASE  WAIT  FOR  AN  ACK- 
NOSLEEGEMENT  CF  SEARCH  COMPLETION  PRIOR  TO  ENTERING 
ANY  EUBTEER  DATA.  YOU  HILL  BE  TOLD  IF  THERE  IS  A  PRO¬ 
BLEM  IN  LOCATING  ANYTHING  ABOUT  YOUS  UNITS. 

***  PFESS  RETURN  TO  CONTINUE  *** 


Figure  3.17  Haster  Database  Search  in  Progress. 


Nhen  you  are  ready  to  continue,  enter  CARRIAGE  RETURN  (as 
described  earlier)  .  You  should  notice  a  short  delay  in  the 
screen  refreshing  as  the  master  database  is  searched.  If 
there  is  nc  difficulty  in  searching  the  master  database, 
than  the  next  query  you  should  see  is  to  determine  which 
unit  will  function  as  ”ZZ.”  (This  is  discussed  under  Battle 
Group  Position  Determination.)  If  a  ship  requires  manual 
capability  information  entry,  then  you  will  be  so  informed. 
Manual  capability  insertion  is  the  subject  of  the  next 
section. 
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c.  Manual  Entry  of  capabilities 

As  we  designed  into  oar  example  battle  group, 
OSS  CALIFORNIA  was  net  a  unit  in  the  master  database.  That 
being  the  case,  yea  woald  see  the  information  shown  in 
Figure  3.18,  indicating  the  units  not  in  the  master  data¬ 
base,  and  requiring  xanual  capabilitiy  entry. 


TEE  FCllCWING  ONUS  WERE  NCT  IN  THE  MASTER  DATABASE 
ANE  WILL  REQUIRE  MANUAL  DATA  ENTRY . 


CAIIfCBNIA 


SINCE  THESE  UNITS  ARE  NOT  IN  THE  MASTER  DATABASE,  THE 
INFORMATION  REG ARCING  THEM  HILL  HAVE  TO  EE  ENTERED 
MANUALLY.  THIS  HILL  REQUIRE  A  KNOHLEDGE  OF  THE  TYPE 
OF  SEKSCRS  AND  HEAEONS  SYSTEMS  ONBOARD.  YOU  WILL  BE 
PRESENTEE  EQUIPMENT  SELECTION/ASSIGNMENT  OPTIONS  IN 
THE  FCRH  OF  EASY  TC  USE  MENUS.  IT  TAKES  APPROXIMATELY 
FIVE  MINUTES  PER  SHIP  TO  ENTER  THE  DATA.  THIS  DATA  IS 
CRITICAL  FOR  THE  CEERATICN  CE  THE  OTHER  MODULES  OF 
TBIS  DECISION  SUPPORT  SYSTEM.  WHEN  YOU  ARE  READY  TO 
CONTINUE ,  ENTER  "YES,”  AND  THE  FIRST  MENU  HILL  APPEAR. 


Figure  3.18  Units  Not  in  the  Master  Database. 


You  must  enter  this  information  for  CALIFORNIA  in  order  for 
the  system  database  tc  be  complete.  when  ycu  are  ready  to 
contirue,  enter  the  following: 


KB  — 
VR  — 


YES  <cr> 

"Affirmative" 


If  ycu  should  enter  anything  other  than  the  YES  response, 
you  will  see  the  following. 

PHASE  ENTER  YES  OR  NO 
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When  yea  are  ready,  and  have  the  required  information,  enter 
YES  as  shevn  above.  He  will  now  follow  the  sequencing  of 
tanual  data  entry  for  OSS  CALIFOBNI A. 

(1 )  fiulj  Number  Determination.  Determination 
cf  the  ship’s  hull  number,  particularly  with  respect  tc  the 
ship  type,  is  very  important  to  the  system.  The  query  for 
this  information  is  shown  in  Figure  3.19. 


FOB 

CALIFORNIA 

??? 

WHAT  IS 

HER 

HOIL  NUMBER  ??? 

(MAXIMUM  CF  SIX  CHAR- 

ACTEBS 

E  »G  • 

SSN688,  DD980, 

FF1075,  ETC.) 

Figure  3.  19  Query  —  Hull  Number  Determination. 


This  entry  from  the  keyboard  is  self- 
explanatory,  remembering  that  there  can  be  NO  blanks  or 
spaces  in  the  hull  number  as  shown  in  the  examples.  Figure 
3.20  shews  the  keyboard  entry  for  CALIFORNIA  as  well  as 
examples  for  other  skip  types. 


CALIFORNIA 

CGN36 

<cr> 

SUBMARINE 

SSN688 

<cr> 

FRIGATE 

FF 1078 

<cr> 

OILER 

AO  1 077 

<cr> 

figure  3.20  Hull  Number  Entry  From  the  Keyboard 


ads  by  sole 
f  th«  irfor 


'  fa  €  keyboard  entries  c 
'he  examples  shown  in  fa 
contained  in  Appendix  A 


seif  ixfi 


TABLZ  I 

Ship  Type  by  Voice 


SAMPLE  VOICE  COMMAND 

"S  ubmarine  '• 

"Aircraft  Carrier" 

"Nuclear  Aircraft  Carrier" 
"Guided  Missile  Cruiser" 

"Nuclear  Guided  Missile  Cruiser" 
"Destroyer" 

"Guided  Missile  Destroyer" 
"Frigate" 

"Guided  Missile  Frigate" 

"Fast  Combat  Support  ship" 
"Replenishment  Oiler" 
"Battleship" 

"Combat  Stores  Ship" 

"Fleet  Oiler" 


For  the  purposes  of  our  example.  Figure 
3.21  shews  the  voice  input  for  the  hull  number  of 
CALIFCENIA.  Should  you  make  an  error  in  entering  either 
response,  you  will  see  the  view  in  Figure  3.22. 


"Nuclear  Guided  Missile  Cruiser"  "Three"  "Six" 
"Carriage  Beturn" 


Figure  3.21  Bull  Humber  Entry  by  Voice. 
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100  BILL  BA?E  TO  REENTER  THIS  V &L0 E 


Figure  3.22  Response  Error  Identification. 

(2)  Groqp  Ass jonment  Determinat ion .  One  of 
the  administra tive  elements  of  the  unit's  database  is  its 
Cruiser-Cestroyer/Carrier  Group  assignment.  This  informa¬ 
tion  in  the  system  is  not  applicable  to  either  Submarines  or 
Service  Force  units,  therefore,  if  the  ship  type  indicated 
in  the  hull  number  cf  a  unit  identifies  it  as  one  of  these 
types,  this  query  will  not  be  presented.  For  our  example, 
the  query  fcr  the  group  assignient  is  shown  in  Figure  3.23. 


FOR  CALIFORNIA 

???  TC  WHICH  CRODESGRO  OF  CARGRO  IS  SHE  ASSIGNED  ???  | 

(1,  3,  5,7,  or  9  (BIDPAC)) 


Figure  3.23  Query  -  Group  Assignment. 


While  the  query  in  Figure  3.23  shews 
"9 (MIEP AC)  , "  as  a  greup  option,  only  the  "9"  is  the  appro¬ 
priate  response  if  applicable.  Your  response  should  be  the 
appropriate  CRUDESGRC/CARGH  0  number.  If-  CALIFORNIA  were 
assigned  to  CRODESGRO  3,  the  following  is  the  format  of  the 
correct  entry. 

KB  —  3  <cr> 

7R  —  "Three”  "Carriage  Return" 
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Should  at  error  occur  in  making  your  response,  the  following 
will  fce  displayed  on  the  screen. 

IIMIT  YOUB  ANSWER  TC  1,  3,  5,  7,  or  9 
***  PRESS  RETURN  TO  CONTINUE  *** 

When  ready,  continue  as  discussed  in  earlier  examples. 

(3)  Squadron  Assignee^  Dete^gi^at iofl.  with 
all  destroyer  and  frigate  ship  types  (as  indicated  in  the 
hull  number),  the  next  query  addresses  the  destroyer 
squadron  assignment.  This  query  will  not  be  presented  for 
non  DE/DEG/FF/FFG  ship  types.  The  query  is  shown  in  Figure 
3.24. 

Your  response  to  this  query  can  be  any  one 
or  twc  digit  number  reflective  of  the  unit's  DESBON  assign¬ 
ment.  For  our  example  battle  group  unit,  CALIFORNIA,  you 
would  not  get  this  query,  as  the  CALIFORNIA  is  a  CGN,  a  unit 
not  assigned  to  a  DESBON.  A  sample  response  to  this  query 
for  F10L  F  FOSTER  would  be  as  follows. 


FOB  PAUL  F  FOSTER 

??  TO  WHICH  DESRON  IS  SHE  ASSIGNED  (IF  APPLICABLE)  ?? 


Figure  3.24  Squadron  Assignment  Determination. 


KE  —  23  <cr> 

YR  --  "Two"  "Three"  "Carriage  Return" 
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Should  you  sake  an  ezzor  in  entering  youz  DESHON  assignment, 
you  Kill  see  the  following: 

ICO  WILL  HAVE  1C  REE  MEF  THE  DESRON  ASSIGNMENT 
***  PRESS  RETORN  TO  CONTINUE  *** 

When  you  are  ready,  enter  CARRIAGE  RETURN, 
then  the  query  shown  in  Figure  3.24  will  be  presented,  and 
you  should  reenter  your  response. 

(4)  Pyiirayv/SeccndarY  Missile  System 

Dgteymjnfltion.  The  determination  of  the 
primary  and  secondary  missile  system  capabilities  are 
addressed  together.  Recognize  that  a  ship  may  have  both  a 
primary  and  secondary  system,  only  a  primary  system,  cr  no 
missile  system  capability  at  all.  Figure  3.25  (adjusted) 
shows  the  available  missile  system  options.  The  following 
will  precede  the  menu  for  determination  of  the  ship's 
primary  irissile  system  capability.  We  will  use  CALIFORNIA 
for  the  sample. 

If  the  ship  has  no  missile  system,  then 
you  would  select  "NOT  APPLICABLE,"  entering  "0".  with  no 
primary  aissile  system  indicated,  you  will  not  be  asked 
about  any  secondary  capability.  Should  you  indicate  that 
the  ship  dees  have  a  primary  missile  system,  then  you  would 
again  receive  the  query  shown  in  Figure  3.25.  This  time, 
the  guery  would  be  prefaced  with  the  following  statements. 

FOB  CALIFORNIA 

???  WHAT  IS  HER  SECONDARY  MISSILE  SYSTEM  (IF  APPLICABLE)  ??? 

In  all  cases,  when  responding  to  these 
gueries,  you  would  indicate  the  appropriate  system  for  that 
ship  ty  entering  the  number  to  the  left  of  that  capability. 
Fcr  CALIFORNIA,  which  has  only  an  SM1-MR  system,  we  would 
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FCB  CALIFORNIA 

???  WHAT  IS  HER  PRIMAFY  MISSILE  SYSTEM  ??? 

*  MISSILE  SYSTEM  OPTIONS  * 

0  NOT  APPLICABLE 

1  NATO  SEASIABROW  MISSILE  SYSTEM  (RIM-7) 

2  STANDARD  MISSILE  SYSTEM  (SM1-ER)  (RIM-67) 

3  BASIC  POIKT  DEFENSE  MISSILE  SYSTEM  (RIM-7, 

4  STANDARD  MISSILE  SYSTEM  (SM2-MR)  (RIM-66C| 

5  STANDARD  MISSILE  SYSTEM  .  . 

6  STANDARD  MISSILE  SYSTEM 


(SM1-MB 

(SM2-ER 


(RIM-66  E, 
(RIM-67EJ 


SELECT  0,  1 ,  2,  3,  4,  5 ,  cr  6 


Figure  3*  25  Query  Menu  -  Missile  System  Options. 

respond  to  the  query  regarding  the  primary  missile  system  as 
follows. 


KB  —  5  <cr> 

VR  —  "Five"  "Carriage  Return" 

Since  ire  indicated  that  CALIFORNIA  has  a 
primary  rissile  system,  then  the  query  for  her  secondary 
missile  system  capability  will  be  presented.  CALIFORNIA  has 
ro  secondary  missile  system,  therefore,  the  response  would 
be  as  fellows. 


KB  —  0  <cr> 

VR  —  "Zero"  "Carriage  Return" 

Should  an  error  occur  in  entering  either 
of  these  values  (prieary/secondary  capability),  you  will  see 
the  following. 

YCO  MCST  LIMIT  YOOB  CHOICES  TO  0 ,  1,  2,  3,  4,  5,  or  6 
***  PRESS  RETORN  TO  CONTINUE  *** 


»  I 


►  4 


»  ^ 

*  'JV.J 


►  t 


l  i 


L  i 
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Continue  as  discussed  earlier,  and  the  appropriate  preface 
(pria ary /secondary)  along  with  the  missile  system  options 
will  appear.  Hake  your  selection  as  demonstrated. 

(5)  H^ypcon  Capability  Determination.  The 
next  query  with  which  you  will  be  presented  will  address  the 
ship*s  Harpoon  weapcns  system  capability.  The  query  is 
shown  in  Figure  3*26. 


figure  3.26  Query  -  Harpoon  Capability. 


The  intent  of  this  capability  determina¬ 
tion  is  tc  oomfirm  net  only  that  the  ship  is  capable  of 
having  the  Harpoon  system,  tut  also  has  the  weapons  onboard. 
As  we  will  see  latex,  this  is  not  a  "one  time"  entry, 
flithin  the  STATUS  module  is  a  capability  to  CHANGE  any  item 
in  the  ship's  database,  and  therefore  allow  for  a  real  time 
maintenance  on  onboard  weapcns.  lour  response  would  be  the 
following,  as  appropriate. 

KE  —  IBS  <cr>  or  NO  <cr> 

VE  —  "Affirmative"  or  "Negative"  " 

If  you  make  a  mistake  in  entering  your  YES/NO  response,  you 
will  see  the  following,  after  which  you  simply  reenter  your 
respense . 

PLEASE  ENTEE  YES  OH  NO 


_  i 


(6)  Prltarv/Seccndary  Air  Search 
Pete  raj-nation.  Similar  to  the  missile  system 
capability  determination,  the  same  menu  is  utilized  for 
deteriination  of  the  primary/secondary  air  search  radar 
capability.  Figure  2.27  shows  the  composition  of  the  menu. 
As  yet  have  seen  before,  the  menu  will  be  prefaced  by  the 
appropriate  declaration  of  which  capability  (primary  or 
secondary)  is  being  solicited.  The  query  for  the  ship's 
primary  capability  is  reflected  in  Figure  3.27.  As 
CALIFCENIA  has  an  AN/SPS-48C,  the  following  would  be  entered 
in  response  to  this  guery. 

KB  —  1  <cr> 

VB  —  "One"  "Carriage  Return" 


FOR  CALIFORNIA 

???  HHAT  IS  HFB  PRIH ARY  AIR 

SEARCH  RADAR  ??? 

*  AIR  SEARCH  RADAR 

OPTIONS  * 

0  —  NONE 

6  —  AN/SPS-37  A 

1  —  AN/SPS-48C 

7  —  AN/SPS-52 

2  —  AN/SPS-49 

8  --  AN/SPS-4  0 

3  —  AN/S  PS-6  5 

9  —  AN/SPS-39 

4  —  AN/SPS-58 

10  —  AN/SPY-1 

5  —  A  N/SPS-43  A 

SELECT  CNE  OF  THE  ABOVE 

Figure  3.27  Query  Benu  -  Air  Search  Radar  Options. 


Once  the  primary  air  search  radar  has  been 
determined,  the  guery  for  the  ship's  secondary  capability 
will  be  presented.  As  you  have  seen  before,  if  ycu  indi¬ 
cate  that  the  ship  has  NO  primary  capability,  then  the  query 
for  the  secondary  capability  will  not  be  presented.  If  you 
indicate  a  primary  capability,  then  the  following  preface 
will  appear. 


JOB  CALIFORNIA 


NHAT  IS  HER  SECONEABY  AI  B  SEARCH  RADAR  (IF  APPLICABLE) 

The  Banner  in  which  the  capability  is  entered  is  the  sane 
for  the  secondary  capability,  and  is  shown  in  the  following 
example,  indicating  CALIFOBHIA  has  an  AN/SPS-40  for  a  secon¬ 
dary  air  search  radar. 

KB  —  8  <cr> 

VB  --  "Eight"  "Carriage  Return" 

Should  an  error  occur  in  entering  either 
the  primary  or  secondary  capability,  the  the  warning  shewn 
in  Figure  3.28  will  be  presented.  On  receiving  such  a 
warning,  simply  enter  CABBIAGE  RETURN,  and  the  appropriate 
preface,  followed  by  the  menu  will  appear.  Then  reenter 
your  response. 


YOU  HILL  HATE  TO  REENTEB  YOUR  RESPONSE  FROM  THE  MENU 
OFTICSS. 

***  PRESS  RETURN  TC  CONTINUE  *** 


Figure  3.28  Naming  -  Response  lot  From  Menu  Options. 


(7)  Surface  Search  Radar  Determination. 
Figure  3.29  shows  the  query  you  will  be  presented  with  for 
the  determination  of  the  ship's  surface  search  radar. 

CALIFCFNIA  has  an  AN/SPS-10  onboard,  therefore,  the  correct 
response  would  be  as  follows. 

KB  —  3  <cr> 
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FCF  CALIFORNIA 

???  NEAT  IS  HER 

SURFACE 

SEARCH  RADAR  CAPABILITY  ??? 

*  SURFACE  SEARCH  RADAR  OPTIONS  * 

0  — 

NONE 

2  — 

AN/BPS-15 

3  — 

AN/SPS-10 

4  — 

AN/SPS-55 

5  -- 

AN/SPY-1 

SELECT  ONE  OF  THE 

ABOVE 

figure  3.29  Query  —  Surface  Search  Radar. 

V R  —  "Three"  "Carriage  Return" 

(8)  Erltarv/Seccndarv  Fire  Control  Radar 
Determination.  Particularly  important  for  the 
combatants  (non-Service  Force  ships)  is  the  specification  of 
their  fire  control  radar  capability.  As  the  system 

addresses  both  primary  and  secondary  capabilities,  the 
procedures  for  entering  this  information  are  similar  to 
those  utilized  with  missile  systems  and  air  search  radars. 
Figure  3.30  shows  the  menu  options  for  fire  control  radars. 
The  guery  for  determination  of  the  primary  capability  is  is 
reflected  in  Figure  3.30. 

Yotr  response  would  be  -he  number  corre¬ 
sponding  to  the  system  you  desire.  If  you  indicate  that 
the  ship  dees  not  have  a  primary  capability,  as  you  have 
seen  before,  you  will  not  be  presented  with  the  query  for 
the  secondary  capability.  A  correct  response  would  look 
like  the  following. 

KB  —  2  <cr> 

VR  —  "Two"  "Carriage  Return" 
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FCS  CALIFORNIA 

???  NEAT  IS  HER  PRIMARY  FIRE  CONTROL  RADAR  (IF  APPLI¬ 
CABLE)  ??? 

*  FIRE  CONTROL  RADAR  OPTIONS  * 


0  —  NONE 

1  —  MK-S1 

2  —  AN/SEG-55  A 

3  --  AN/SPG-49 

4  —  AN/SEN-2 

5  —  NK-40 

6  —  AN/SEG-51 

7  —  MK- 1 

8  —  MK-76 

9  --  MK- 56 


SELECT  CNE  OF  THE  ABOVE 


10 

11 

12 

13 

14 

15 

16 

17 

18 


-  MK-99 

-  MK-74 

-  MK-68 

-  MK- 92 

-  AN/SPG-53 

-  AN/SPG-60 

-  MK- 13 

-  AN/SPQ-9 

-  AN/SPG-35 


Figure  3.30  Query  Beau  -  Fire  control  Radar  options. 

If  yon  indicate  a  primary  capability,  the 
query  fcr  the  secondary  capability  will  appear  with  the 
following  prefacing  the  menu  options. 

FOR  CALIFCBNIA 

N HAT  IS  EFR  SECONDARY  FIRE  CONTROL  RADAR  (IF  APPLICABLE) 

The  response  for  the  secondary  capability 
is  of  the  same  format  as  the  primary.  Should  an  error 
cccur  in  entering  ycur  response,  you  will  see  the  warning 
shown  in  Figure  3.28.  As  was  discussed,  when  ready,  enter 
CARRIAGE  RETURN  and  the  appropriate  preface  and  menu  will 
appear.  Reenter  your  response. 

(9)  UHF/HF  Radio  Capability  Deter  miration. 
One  cf  the  important  capabilities  of  the  system  is  to 
display  the  communications  links  within  the  battle  group. 
This  is  done  in  the  CCMMS  module.  The  graphics  displays  of 
the  nets  is  color  coded  to  show  not  only  the  relative 
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distance  between  participating  units,  but  also  their  respec¬ 
tive  radio  requirements  based  on  mission  area.  The 
dynamics  of  the  status  of  communications  equipments  makes 
this  a  good  indicator  of  C3  performance.  The  base  for  the 
determination  of  the  available  radios  onboard  is  the  attri¬ 
tion  applied  to  installed  numbers  of  those  radios.  This 
number  of  installed  radios  is  the  value  desired  in  this 
query.  The  system  will  differentiate  between  DBF  and  HF 
radios.  The  query/response  sequence  is  straightf oward. 
The  query  for  the  number  of  installed  OHF  radios  is  shewn  in 
Figure  3.31 . 


FCB  CALIFORNIA 

???  HOW  NANY  OHF  RADIOS  DOES  SHE  HAVE  ONBOARD  ??? 
(RANGE  1  TO  99) 

i  . . . . . . . .  . . . . . 


Figure  3.31  Query  -  oh?  Radio  capability. 


Identical  tc  the  format  for  the  OHF  query, 
the  query  for  the  numbers  of  installed  HF  radios  is  shewn  in 
Figure  3.32. 


The  response  to  either  if  these  queries  is 
of  the  same  format  and  an  example  is  as  follows. 

KB  —  15  <cr> 

VE  --  "Cne"  "Five"  "Carriage  Return" 

If  year  response  is  net  within  the  range  specified  (1  -  99), 
then  you  will  see  the  warning  shown  in  Figure  3.33  on  the 
screen. 
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FOB  CALIFORNIA 

???  HCW  WANT  HF  RAEIOS  DOES  SHE  HATE  ONBOARD  ??? 
(BANG!  1  TO  99) 


Figure  34  32  Query  -  HF  Radio  Capability. 


< — — •  — - — — — - - — - - -  —  — - , 

TOO  HILL  HAVE  TO  BEENTER  THIS  NUMBER 
***  PRESS  RETOBN  TC  CONTINUE  *** 


Figure  3.33  EBROR  in  Entering  Integer  value. 


After  you  enter  CARRIAGE  RETURN,  the  applicable  query  will 
reappear  and  you  can  reenter  ycur  response. 

0°)  Satellite  Communications  capability 

Determination.  To  complete  the  database  for 
the  communications  capabilities  of  th9  ship,  you  need  to 
identify  the  ship's  satellite  comm  capability.  This  is 

very  straightf oward,  and  the  query  is  shown  in  Figure  3.34 
(adjusted).  To  give  the  ship  a  capability  indicated  in  the 
menu,  sieply  enter  the  number  corresponding  to  the  eguipment 
desired. 


If  you  desire  to  indicate  that  CALIFORNIA 
has  an  AN/NSC- 3  onboard,  your  response  would  look  like  the 
following  example. 

KB  —  1  <cr> 
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???  W BAT  SATELLITE  COSMO NICATION S  CAPABILITT  DOES  SHE 
HAVE  ??? 


0 

1 

2 

SELECT  0,1,  CB  2 


DC  HE 

AN /R SC- 3 
OE-82 


Figure  3.34  Query  -  Satellite  Communications  Capability. 

VR  --  "One"  "Carriage  Return" 

Should  you  make  an  error  in  entering  this 
response,  tken  the  warning  shown  in  Figure  3.28  will  appear. 
After  yen  enter  CARRIAGE  RETURN,  the  SATCOH  menu  will  reap¬ 
pear,  and  you  can  reenter  ycur  response. 

(11)  Gas  Systea  Capability  Determination.  The 
next  input  to  the  ship's  database  is  her  gun  weapons  system 
capability.  Figure  3.35  (adjusted)  shows  the  query  menu 
with  the  available  gun  optiens. 

CALIFORNIA  has  a  5"/54  MK45  gun.  The 
following  is  an  example  of  how  we  would  anter  this  informa¬ 
tion. 


KB  —  5  <cr> 

V R  —  "Five"  "Carriage  Return" 

The  warning  shown  in  Figure  3.28  will 
appear  if  ycur  response  is  not  within  the  range  of  the  menu 
options  (0  -  7) .  After  you  enter  CARRIAGE  RETURN,  the 

guery  menu  will  appear  and  you  can  reenter  your  response. 


FOE  CALIFORNIA 

???  WHAT  IS  HER  GON  WEAPONS  SYSTEM  CAPABILITY  ??? 

*  GON  SYSTEM  OPTIONS  * 

0  —  NCT  APPLICABLE 

1  —  16"/50 

(406  mm)  MK7  MOD  0  1 

2  —  5M/38  (127  mm)  MK12  MOD  1 

3  —  2am/70 

MK4 

4  —  5"/54  i 

,127  mm)  MK42 

5  —  5"/54 

1 27  mm)  MK45 

6  —  3"/50 

'76  at)  MK22 

7  —  76  mm 

;OTO  HELARA) 

SELECT  ON  OF  THE  AEOVE 

figure  3.35  Query  -  Gun  Systen  Options. 

(12)  PHALANX  Capability  Determination.  The 
guery  shewn  in  Figure  3.36  requests  the  number  of  PHALANX 
systems  the  ship  has  onboard.  The  number  of  systems  can 
range  ficm  mero  (0)  through  normally,  four  (4). 


FOE  CALIFORNIA 

???  HOW  MANY  PHALANX  SYSTEMS  DOES  SHE  HAVE  ??? 


* 


► 


l 


f 


l 


) 


Figure  3.36  Query  -  PHALANX  Capability. 

I 

To  indicate  that  CALIFORNIA  has  three  (3) 

PHALANX  systems  onboard,  the  fcllowing  entry  would  be  made. 

Should  an  error  occur  in  making  this  entry,  the  warning 
shown  in  Figure  3.33  will  appear,  and  when  you  continue,  the 
query  will  again  come  up,  and  you  cna  reenter  your  response. 

KB  —  3  <cr> 

S7 


t 


"Three”  "Carriage  Return" 


YR 

(13)  TQfApAWK  Capability  Deterainat ion.  while 
the  1CMABANK  weapons  system  is  relatively  new  to  the  fleet, 
this  capability  will  beccae  increasingly  available  in 
upcoaing  years.  To  ensure  that  this  DSS  has  the  ability  to 
display  the  TO MA HARK  capability,  this  solicitation  for 
infoxaaticn  will  be  presented.  The  query  shown  in  Figure 
3.37  requests  the  ship's  TOMAHAWK  capability.  In  the  case 
cf  our  exaaple,  California,  she  does  not  have  this  capa- 
tility. 


FOB  CALIFORNIA 

111  IS  SHF  TOMAHAWK  CAPABLE  ???  (YES  OR  NO) 


Figure  3.37  Query  -  TOMAHAVK  Capability. 


There  is  a  difference  in  the  intent  of 
this  query  as  opposed  to  that  of  the  HARPOON  capability. 
With  1C MAH A WK,  it  is  assun ed  that  since  few  ships  have  this 
capability,  those  tbat  do  will  have  the  weapons  onboard, 
lherefore,  a  "YES"  response  to  this  query  should  nean  that 
the  ship  in  question  has  not  cnly  the  capability,  tut  also 
the  weapons.  Your  response  would  be  the  following  as 
applicable. 

KB  —  YES  <cr>  or  NO  <cr> 

VB  —  "Af firaati ve"  or  "Negative" 

Should  an  error  occur  in  making  this  response,  you  would  see 
the  following  on  the  screen. 

PHASE  ENTER  YES  OR  NO 
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04)  aaiicgptgi  £ae aliilisi  msiair&iiio.  ihe 
helicopter,  as  a  surveillance  vehicle  or  a  weapons  platform 
is  beccaing  invaluable  to  the  battle  group.  The  query, 
shown  in  Figure  3.38,  requests  inforaation  on  the  helicopter 
capability  cf  the  ship  in  question.  The  four  helo  types, 
present  is  a  battle  group  are  shown  as  options.  Cnee  the 
capability  has  been  affirmed,  then  you  will  be  asked  whether 
the  the  ship  actually  has  its  detachment  onboard. 


Figure  3.38  Query  *  Helicopter  Capability  Deter Bination. 


For  CAL1I0FHI&,  which  has  a  LAHPS  capability,  your  response 
would  he  the  the  following. 

KB  —  5  <cr> 

?8  —  "Five"  "Carriage  Return" 

Once  the  capability  has  been  determined  to 
exist,  you  will  receive  a  query  regarding  the  embarcation 
status  of  the  detachaent.  This  query  is  tailored  to  the 
type  cf  capability  you  gave  the  ship.  For  our  example. 
Figure  3.39  shows  the  query. 


???  DO IS  CALIFOBNIA  HAVE  HER  LAMPS  DET  ONBOARD  ??? 
(IIS  CE  NO) 


figure  3.39  Query  -  LAMPS  Embarcation  Status. 

As  Has  mentioned,  this  query  is  tailored 
to  the  type  of  capability  you  gave  the  ship.  If  you  had 
indicated  ttat  the  skip  had  an  HC  DET  (CH-46)  capability, 
then  the  following  would  be  the  query  for  the  eabarcation 
status. 

???  DOES  < SHIP>  HAVE  HER  "CH46"  DET  ONBOARD  ??? 

(IES  CB  NO) 

There  are  similar  Batches  for  each  capability  listed  in 
Figure  3.38. 

At  this  point,  an  additional  capability  of 
the  system  needs  to  be  addressed.  He  will  discuss  in  the 
STATES  acdule  operations,  the  capability  you  will  have  to 
change  any  item  in  tfce  ship*s  database  once  the  battle  group 
ha.  been  established.  That  capability  utilizes  tha  saae 
■enus  and  prefaces  as  does  the  module  in  which  we  are 
working.  While  that  capability  will  be  covered  in  mere 
depth  later  (under  STATUS  Module  Operations),  reference  will 
regularly  be  made  to  these  sections  for  explanation  of  the 
queries  and  appropriate  responses  with  respect  to  the  menus. 
When  dealing  with  the  helicopter  embarcation  status  CHANGE 
Cllfol ,  there  is  a  warning  that  could  appear  if  you  attempt  to 
embark  a  helicopter  detachment  on  a  ship  to  which  there  has 
teen  given  NO  helo  capability.  In  this  case,  the  warning 
shown  in  Figure  3.40  will  be  presented. 
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BASED  CH  THE  INFOE RATION  IN  THE  DATABASE,  THIS  ONIT  IS 
NOT  E 110  CAPABLE.  TOO  HILL  HATE  TO  FIRST  6ITE  HEB  THE 
CAPABILITY. 

**♦  PRESS  RETORN  10  CONTINOE  *** 


Figure  3.40  Ranking  -  Ship  Not  Halo  Capable. 

This  situation  is  not  possible  when 
working  in  the  BOILD  sodule,  which  we  are  discussing,  as  you 
will  rot  be  queried  cn  the  embarcation  status  of  a  ship  to 
which  you  gave  no  helc  capability. 

Should  an  error  occur  in  aaking  the 
response  regarding  the  capability,  the  warning  shown  in 
figure  3.28  will  appear.  After  you  continue,  you  will 
again  be  presented  with  the  aenu,  and  can  reenter  ycur 
response.  Should  an  error  occur  when  you  are  aaking  ycur 
response  regarding  the  enbarcaficn  status,  you  will  see  the 
following  on  the  screen. 

PLEASE  ENTER  YES  OR  NO 

At  this  pcint,  siaply  reenter  yor  YES/NO  response. 

(15)  Sonar 7ITD  s  Capability  Deteraination.  The 
guery  for  the  ship's  sonar  capability,  shown  in  Figure  3.41, 
will  net  be  presented  for  the  Aircraft  Carriers,  or  Service 
Force  ships.  Also,  the  assignment  of  the  senar  capability 
is  iapertant  because  in  the  SENSOR  aodule,  some  of  the 
sonars  are  "flagged"  as  being  capable  for  convergence  zone 
operations,  and  that  capability  will  be  displayed  if  you 
indicate  that  those  conditions  exist. 


t 


101 


FOB  CALIFORNIA 

???  8HAT  IS  HER  SONAR  CAPABILITY  ??? 


*  SONAR  OPTIONS  * 


0 

1 


a 

5 


NOT  CAEABLE 

AN/BQC-5 

AN/BQS-15 

AN/BQC-2 

AN/BQS-6 

AN/BQB-7 


6  —  AN/BQS-12 

7  —  AN/SQS-23 

8  —  AN/SQS-26 

9  —  AN/S QQ- 23 

10  —  AN/SQS-53 

11  —  AN/SQS-56 


Figure  3.41  Query  -  sonar  Options. 

You  would  indicate  the  sonar  capability  be 
entering  the  nueber  corresponding  to  the  equipment  desired, 
for  CALIFORNIA,  which  has  an  AN/SQS-53  sonar,  your  response 
would  lock  like  the  following. 

KB  —  10  <cr> 

VR  —  "One"  "Zero"  "Carriage  Return" 

Should  an  error  occur  in  making  this  response,  the  informa¬ 
tion  shown  in  Figure  2.28  would  appear.  8hen  you  continue. 
Figure  3.41  will  reappear,  and  you  can  reenter  ycur 
response. 

The  IVDS  capability  determination  is  stra- 
ightfcward,  and  requires  only  a  YES/NO  answer.  The  query 
for  this  information  is  shown  in  Figure  3.42. 


CALIFORNIA  does  not  have  this  capability, 
therefore  we  would  enter  NO.  The  response,  in  general, 
would  be  the  following  as  applicable. 

KB  —  YES  <cr>  or  NO  <cr> 

FR  —  "Affirmative"  or  "Negative" 
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FCB  CALIFORNIA 

???  DCES  SHE  HAVE  AH  I?DS  CAPABILITY  ???  (YES  OS  NC) 


Figure  3.42  Query  -  IVDS  Capability. 


Should  ycu  sake  an  error  in  responding,  you  will  be  directed 
to  enter  your  YES/SC  response  again,  as  we  have  seen 
earlier. 


O6)  TASS  Capability  Determination.  The 

deteninaticn  of  the  TASS  capability  applies  to  only  to 
submarines,  destroyers,  cruisers  and  frigates.  This  query 
will  net  be  presented  for  ships  not  in  those  ship  types. 
Figure  3.43  shows  the  composition  of  the  query. 


figure  3.43  Query  -  TASS  Capability. 


The  response  to  this  query  is  the  number  corresponding  to 
the  desired  capability.  CALIFORNIA  does  not  have  this 

capability,  therefore  the  response  would  be  as  follows. 

KB  —  0  <cr> 

YR  —  "Zero"  M  carriage  Return** 
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Should  as  error  occcr  is  Baking  this  response,  then  the 
warning  shown  in  Figure  3.26  will  be  presented.  After  you 
continue,  the  ?ASS  Capability  nenu  will  again  be  presented, 
and  you  can  reenter  ycur  response. 

(17)  A?J  Rccket/Torpedo  Cacabilitv 


(17)  A?J  Rccket/Torpedo  Capability 

Pete ruination.  The  determination  of  the  ASW 
weapons  capability  for  the  units  of  the  battle  group  is 
discussed  together.  These  capabilities  are  not  applicable 
to  aircraft  carriers  and  service  force  ships,  and  therefore 
the  gueries  will  not  be  presented  for  those  units.  The 
composition  for  the  query  for  determination  of  the  AS? 
rocket  capability  is  shown  in  Figure  3.44. 


FOB  CALIFORNIA 


???  WHAT  IS  HER  AS W  RCCKET  CAPABILITY  ??? 

N  —  NOT  APPLICABLE 
A  —  ASROC 
S  —  SOB  HOC 


figure  3.44  Query  -  ASH  Rocket  capability. 


This  is  the  first  query  menu  that  requires  a  response  that 
is  a  character  and  net  a  number.  Also,  there  is  no  system 
check  of  the  input  ycu  make,  sc,  you  could  give  a  SOBRCC  (a 
submarine  weapon)  to  a  surface  ship.  This  fact  is 
mentioned  net  to  encourage  you  to  do  this,  but  rather  to 
alert  you  to  the  possibility  of  error  without  system  correc¬ 
tion.  The  response  desired  is  made  by  entering  the  char¬ 
acter  corresponding  to  the  desired  capability.  CALIFORNIA 
has  an  ASROC  capability,  therefore  the  response  would  be  as 
follows. 


KB  — 
V  R  - 


A  <cr> 
"  ASRO C"  "Carriage  Return" 
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The  system  looks  for  a  response  that  has  no  numbers  and 
either  the  "H,"  "A,"  or  "S"  characters.  Should  ycur 
respcsse  net  be  any  cf  those  inputs,  then  you  will  see  the 
warning  shown  in  Figure  3.2  8.  After  you  continue,  the  menu 
will  be  again  presented,  and  you  can  raenter  your  respense. 

The  determination  of  the  ship*s  torpedo 
capability  is  similar  to  other  queries  you  have  seen.  The 
composition  for  the  query  is  shown  in  Figure  3.45. 


FCB  CALI  BOSNIA 

???  W  EAT 

IS  HER  TORPEDO  CAPABILITY  ??? 

C  —  NOT  APPLICABLE 

1  —  MK 46 

2  —  MK 48 

_ 1 

Figure  3.45  Query  -  Torpedo  Capability. 


The  input  should  be  the  number  corresponding  to  the  desired 
capability.  CALI  ECRNIA  has  a  MK46  torpedo  capability, 
therefore,  the  correct  response  would  ba  as  follows. 

KB  —  1  <c:> 

7R  —  "One"  "  Carriage  Return" 

Should  an  error  occur  in  making  this  response,  the  the 
warning  shown  in  Figure  3.28  will  be  presented.  After  you 
continue,  the  menu  will  ha  again  presented  and  you  can 
reenter  ycur  response. 
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(18)  fl&iifiM  Soee^  Determination.  The  desired 
value  of  this  input  is  the  designed  maximum  speed  for  the 
ship  in  guestion.  In  the  CHANGE  function  of  the  STATUS 
■odule,  this  value  can  be  kept  current,  as  a  real  time  indi¬ 
cator  of  the  ship's  icbility  capability.  In  the  STATUS 
■odule,  you  can  adjust  this  value  as  the  situation  dictates. 
The  ccapcsition  for  the  query  is  shown  in  figure  3.46  . 


FCB  CALIFORNIA 

???  WHAT  IS  EER  MAXIMUM  SPEED  IN  KNOTS  ??? 
(RANGE  1-40  KNOTS) 


Figure  3.46  CPery  -  Maximum  Speed  Capability. 


The  response  to  this  query  should  be  the  ship's  maximum 
speed,  within  the  ranee  given  (1-40  knots)  .  The  CAIIFCRNIA 
has  ar  unclassified  maximum  speed  of  33  knots,  and  this 
information  would  be  input  as  follows. 

KB  —  33  <cr> 
vb  —  "Three"  "Three"  "Carriage  Return" 

The  system  will  check  the  input  to  ensure  that  it  is  within 
the  allcvatle  range.  Should  the  input  not  be  within  this 
range,  the  warning  shown  in  Figure  3.33  will  be  presented. 
After  yee  continue,  tha  query  shown  in  Figure  3.46  will 
again  be  presented,  and  you  can  reenter  your  response. 

(19)  Capability  Determination.  The 
composition  of  the  query  fer  a  ship's  SLQ-32  capability  is 
shown  in  Figure  3.41.  The  required  input  is  a  YES  or  NO 
cespccse. 
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FOB  C2LIFOBNI& 


???  DOES  SHE  EAVE  AN  SLQ-32  CAPABILITY  ??? 

(YIS  CB  NO)  | 

_ I 


Figure  3.47  Query  -  SLQ-32  Capability. 


CALIFORNIA  does  not  have  this  capability,  therefore  the 
correct  response  would  be  NC.  As  applicable  to  the  partic¬ 
ular  ship,  the  response  would  ke  as  follows. 

KE  —  YES  <cr>  or  NO  <cr> 

VF  —  "Affirmative"  or  ••Negative" 

Should  ar  error  cccur  in  making  this  response,  the  following 
statement  will  appear. 

PLEASE  ENTEB  YES  OB  NO 

If  this  occurs,  simply  reenter  your  YES/NO  response. 

(20)  Primarv/S eccndarv  Mission  Determination . 
The  sane  menu  is  utilized  for  the  determination  of  both  the 
primary  and  secondary  missions  of  a  ship.  Figure  3.49 
shows  the  composition  of  this  menu.  The  specific  mission 
desired  (primary  or  secondary)  will  be  specified  in  a 
preface  to  the  menu.  The  preface  for  the  determination  of 
the  ship's  primary  mission  is  shown  in  Figure  3.48.  For 
the  purposes  of  this  system,  every  ship  MUST  have  a  primary 
mission.  Therefore,  you  will  not  be  allowed  to  enter  "NOT 
APPLICABIE"  for  a  ship’s  primary  mission. 


FCB  CALIFORNIA 

???  WHAT  IS  HER  SECONDARY  HISSION  ??? 


Figure  3.50  Goer?  -  Secondary  Hission  Area. 

This  query  would  be  Yellowed  by  the  mission  options  shown  in 
Figure  3.49.  The  CALIFORNIA  has  a  secondary  mission  of 
ANTI-SOEKARINE  HAEFAEE,  therefore  the  correct  input  for 
secondary  mission  area  would  be  as  follows. 

KB  —  ASH  <cr> 

VR  —  •'Anti-Submarine  Harfare" 

The  systex  will  attempt  to  match  your  response  to  these 
options  shewn  in  the  menu,  and  if  there  is  no  match ,  an 
error  will  occur.  Should  this  happen,  the  warning  shown  in 
Figure  3.28  will  be  presented.  After  you  continue,  the 

applicable  query  will  again  be  presented,  and  you  can 
reenter  your  response. 

d.  Completion  of  Database  Assembly 

The  complete  sequence  of  capability  menus,  as 
applicable  to  the  ship  types  in  question,  will  be  presented 
for  all  ships  listed  in  the  view  shown  in  Figure  3.18. 
Cnee  these  capabilities  have  been  compiled  for  all  cf  the 
ships  in  the  battle  croup,  whether  it  be  done  automatically 
or  manually,  you  are  ready  to  proceed  to  the  next  phase  of 
Initially  Forming  the  battle  group  database,  determination 
cf  the  positions  of  the  ships.  This  is  the  topic  of  the 
next  section. 
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e.  Establishing  Unit  Eos it  ions 

Now  that  the  names  and  capabilities  of  the  ships 
which  will  coaprise  the  battle  group  have  been  determined, 
the  next  information  required  by  the  system  is  the  position 
cf  each  ship.  There  are  generally  three  segments  to  this 
section  of  the  BOXLD  sodule.  First,  the  unit  which  will  be 
in  "ZZ"  will  be  determined.  fieaember  that  for  the  purposes 
of  this  system,  a  battle  group  ship  must  be  at  "ZZ."  Next, 
the  type  cf  coordinate  system  to  be  used  (polar  cr  carte¬ 
sian)  ,  will  be  determined.  Finally,  the  positions  for  the 
individual  ships  will  he  input.  Let's  first  look  at  deter- 
xining  the  unit  to  be  at  "ZZ." 

(1)  Determination  c$  "2JZ"  unit.  The  specifi¬ 
cation  of  the  unit  tc  be  at  "ZZ"  is  critical  to  the  opera¬ 
tion  cf  the  remainder  of  the  modules  in  the  system.  It  is 
with  respect  to  this  unit  that  all  of  the  computer  graphics 
coordinates  for  each  ship  will  be  calculated.  The  calcula¬ 
tion  cf  these  graphics  coordinates  is  done  by  the  system  and 
will  he  transparent  tc  you.  The  only  information  required 
will  he  the  normally  assigned  ship  positions,  in  terms  of 
the  cccrdinate  system  you  select,  and  the  system  will  adapt 
those  positions  for  graphics  use.  Irrespective  of  the  coor¬ 
dinate  system  you  specify,  the  position  of  the  unit  at  "ZZ" 
will  have  to  be  input  in  cartesian  coordinates,  as  these 
adapt  more  readily  tc  graphics  coordinates.  This  query 
will  be  discussed  shcrtly. 

The  query  shown  in  Figure  3.51  addresses 
the  determination  of  the  unit  to  be  at  "ZZ."  As  you  will 
now  see  throughout  the  remainder  of  this  Decision  Support 
System,  whenever  a  requirement  is  levied  to  name  a  partic¬ 
ular  unit  cf  the  battle  group,  there  will  be  a  current 
listing  of  the  tattle  group  provided  along  with  the  query. 
This  listing  shows  all  of  the  battle  group  units  as  the 
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system  has  filed  their  names.  Figure  3.51  shows  the  compo¬ 
sition  of  our  example  battle  group  to  assist  you  in  identif¬ 
ying  the  unit  you  desire. 


???  WHICH  UNIT  WILL  FUNCTION  AS  ZZ  ??? 
CAEL  VINSON  PAUL  F  FOSTER  CALIFORNIA 


Figure  3.51  Query  -  Name  of  ZZ  Onit. 


The  listing  of  ships  will  always  be  in  three  columns. 
Since  there  are  only  three  ships  in  the  example  tattle 
group,  there  is  only  one  line.  As  you  found  when  you 
entered  the  names  of  the  ships  earlier,  the  spelling  of  the 
name  is  critical  fcr  the  system  to  recognize  the  entry. 
Every  time  there  is  a  request  for  identification  cf  a  unit, 
the  system  will  attempt  to  match  the  input  name  tc  those  in 
the  tattle  group.  Should  a  match  not  occur,  then  you  will 
be  asked  tc  reenter  the  response.  In  order  to  use  the  name 
cf  a  unit,  for  any  function,  it  must  be  first  INSERTed  into 
the  battle  group  database,  as  we  have  already  done  for  cur 
three  example  ships.  Sven  though  the  listing  shews  "PAUL  F 
FOSTER, "  the  system  has  been  programmed  to  recognize 
"FOSTER"  as  an  acceptable  version  for  the  same  ship.  This 
is  alsc  true  for  "CAEL  VINSON",  as  the  system  will  recognize 
"VINSCN"  as  the  same  ship.  In  general,  this  applies  tc  all 
ships  with  two  or  more  words  in  their  names.  The  last  name 
cf  the  ship  has  been  programmed  to  be  an  alternatively 
acceptable  name  representaticn.  These  differences,  in 
reality,  apply  both  to  keyboard  as  well  as  voice  entry. 
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For  voice  entry,  refer  to  Appendix  A  for  a  detailed  listing 
of  all  legitimate  ship  names  and  their  variations.  let's 


assign  tke  CAHL  VINSCK  to  "ZZ." 
te  as  fellows. 

KB  —  CABL  VISSON  <cr> 

V B  —  "CARL  VINSON" 

If  there  was  a  aechanical  error 
the  following  alert  would  be  dis 

PLEASE  BIENTIB  THE  NAME 


The  correct  response  would 

or  vinson  <cr> 
or  "VINSON" 

in  aaking  this  entry,  then 
played. 

OF  THE  ZZ  UNIT  AGAIN 


If  there  had  not  been  a  match  of  the  input  name  with  these 
of  the  listing  (for  example  if  you  had  input  NIMITZ) ,  then 


YOUR  ENTFY  FOR  ZZ  NIMITZ  DOES  NOT  MATCH  ANY  OF  THE 
SHIE  NAMES  IN  YOUE  EATTLE  GEOOP.  PLEASE  CHECK  TEE 
SPELLING  AND  COMPLETENESS  OF  YOUR  ENTRY. 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.52  ERHCB  -  ZZ  Haae  Not  Matched  To  Listing. 

you  would  be  shown  the  warning  shown  in  Figure  3.52. 

Hhen  you  continue,  you  will  again  be  presented  with  the 
guery  shewn  in  Figure  3.51,  and  you  can  reenter  your 
response. 

The  next  guery  you  will  see  is  for  deter¬ 
mination  of  the  coordinate  system  to  be  utilized. 

(2)  Determinat ion  of  Coordinate  system.  There 
are  two  choices  for  coordinate  systems  on  which  to  base  your 
ship's  positions,  polar  or  cartesian.  The  query  which 

addresses  the  coordinate  system  is  shown  in  Figure  3.53 
(adjusted)  . 
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TOO  Will  NOW  BE  ASKED  FOB  TEE  POSITION  OF  EACH  UNIT  IN 
THE  EATT1E  GROUP. 


???  WCULC  YOU  LIKE  TO  USE  POLAR  OR  CARTESIAN  POSI 
TICNS  ??? 

(EBTEE  "POLAR"  OR  "CARTESIAN") 


Figure  3.53  Query  -  Coordinate  Systea. 


The  format  of  the  response  to  this  query,  as  well  as  the 
guery  sequences  which  respectively  follow  each  response 
option  are  shown  in  subsequent  sections.  Should  you  make 
an  error  in  entering  the  response  to  the  query  shown  in 
Figure  3.53,  the  following  will  be  presented. 

PLEASE  ENTER  "PCLAF"  OR  "CARTESIAN" 

Feaea her  not  to  include  the  quotes.  Once  the  type  of  coor¬ 
dinate  systea  has  been  specified,  you  are  asked  for  the 
cartesian  position  of  the  unit  at  "ZZ"  (CARL  VINSON,  in  our 
ezaaple) .  This  query  is  shown  in  Figure  3.54. 


FCB  CIRL  VINSON 

???  WEAT  IS  HER  POSITION  IN  CARTESIAN  COORDINATES  ??? 

(ENTER  AS  QUADRANT  (R,W,E,G),  SPACE,  X-POSITION,  SPACE, 
i -POSITION) 

(E.G.  W  030  090) 


figure  3.5*  Query  -  Cartesian  Position  of  ZZ  Unit. 


I 
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?h«  format  cf  the  response  to  this  query, 
and  th«  corracticns  tc  any  errors  which  yea  sight  encounter 
in  eaking  this  response,  are  identical  to  those  which  you 
see  for  the  input  cf  a  cartesian  position  for  any  ether 
ship.  Please  refer  tc  the  section  on  Query  Sequences  — 
Cartesian  Coordinate  System,  below.  This  will  be  the  only 
tiae  you  are  asked  for  the  position  of  the  unit  at  "ZZ," 
unless  you  delete  this  unit  free  the  battle  group,  in  which 
case  you  will  have  tc  reinitiate  the  position  deterainatioc 
sequences.  Me  will  new  lock  at  the  sequences  which  you 
will  enccunter  based  on  the  type  of  coordinate  systea  you 
specify. 

(3)  fla3i2  saaasflssg  —  Eaiat  sagii&ais 
Svstef .  In  response  to  the  query  shown  in 
Figure  3.53,  if  you  desire  to  input  battle  group  positions 
in  pclar  coordinates,  the  correct  foraat  for  the  response 
would  be  as  follows. 

KB  —  POLAR  <cr> 

VE  —  "Polar  Coordinate  System" 

Once  you  have  selected  this  coordinate  systea,  you  will  be 
sequence  through  each  ship  (less  the  unit  at  "ZZ") ,  being 
queried  for  its  bearing  and  range  from  "ZZ."  You  will  first 
be  asked  for  the  ship’s  bearing  from  "ZZ,"  in  degrees  true. 
Next,  ycu  will  be  asked  for  the  ship's  range  from  "ZZ,"  in 
YABQS.  After  you  have  entered  a  ship's  position,  that 
positicn  will  be  presented  to  you  for  confirmation.  The 
initial  cuery  is  shown  in  Figure  3.55. 

If  P ACL  F  FOSTEB  were  bearing  090  degrees  true  from  "ZZ," 
then  the  correct  response  tc  this  query  would  be  as  follows. 

090  <cr> 

"Zero"  "Nine"  "Zero"  "Carriago  Return" 


KB 

VB 


nu 


POS  P10L  P  FOSTEB 


???  3 HAT  IS  HEP  BEARING  AND  RANGE  FROM  ZZ  ??? 

???  E EARING  ??? 

(ISIIB  AS  THREE  DIGITS  000-359) 

figure  3.55  Query  -  Ship's  Bearing  Pros  ZZ. 

The  system  mill  check  the  input  against  the  authorized  range 
(000-359),  and  should  the  input  not  be  within  this  ranee, 
then  the  following  warning  will  be  presented. 

PLEASE  ENTER  AS  THREE  DIGITS  (000-359),  RI1HOOT  COMMAS  OR 
CECIBAL  POINTS 

***  PRESS  RETORN  TO  CONTINOE  *** 

ihen  ycu  continue,  you  will  again  be  presented  with  the 
query  shows  in  Figure  3. 55,  and  you  can  reenter  your 
response. 

You  will  next  be  asked  tc  indicate  the 
ship's  range  from  "ZZ."  This  range  input  should  be  in 
yards,  and  entered  without  any  commas  or  decimal  points. 
The  query  is  shown  in  Figure  3.56. 

As  an  example,  PAOL  E  FOSTER  is  50,000  yards  (25  nm)  from 
"ZZ."  The  correct  response  to  this  query  wculd  be  as 
follows. 

KB  —  50000  <cr> 

7R  —  ""Five"  "Zero”  "Thousand” 

Should  an  error  occur  in  making  this  entry,  the  warning 
shown  in  Figure  3.57  would  be  presented. 


FOB  FAOL  F  FOSTER 

???  SHAT  IS  THE  SHIEMS  BANG  £  FBOM  ZZ  ???  (IN  TARCS) 

(EBTSB  AS  SIX  DIGITS  SITHOOI  COMMAS  OR  DECIMAL  POINTS 
E.G.  10,000*10000  RANGE  LIMITS  0  TO  600,000  TARES) 


Figure  3.56  Query  -  Range  Froa  ZZ. 


PLEASE  ENTER  THE  RANGE  AS  SIX  DIGITS  WITHOUT  COMMAS  CR 
EECIEAL  POINTS. 

(E.G.  5,000*5000,  500,000*500000,  ETC.) 

***  PRESS  RETORN  TO  CONTINOE  *** 


Figure  3.57  EBBOB  -  Range  Input. 

when  you  continue,  the  query  for  range 
(Figure  3.56)  will  again  be  presented,  and  you  can  reenter 
your  response.  The  system  will  also  check  your  input 
against  the  range  limits  (0  to  600,000  yards) .  Should  your 
input  not  be  within  these  limits  (for  example  700000  was 
input),  then  the  warning  shown  in  Figure  3.58  will  be 
presented.  As  with  other  error  corrections,  when  you 
continue,  the  original  query  will  be  presented,  and  you  can 
reenter  year  response. 


Once  the  bearing  and  range  have  been 
correctly  input,  the  values  are  presented  to  you  for  confir¬ 
mation.  The  format  for  this  confirmation  is  shown  in 
Figure  3.59,  and  requires  a  YES/NO  response. 


TOO  HIVE  ENTERED  7C0000  AS  THE  BANGS  AS  THIS  UNIT'S 
BANG!,  AND  THIS  IS  NOT  HITBIN  THE  BANGS  LIMITS . 
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Figure  3.58  BBBCB  -  Bang*  Outside  Prescribed  Lisits. 


PAUL  F  FCSTEB  IS  EiABING  90  DEGBEES  THUS  AND  BANGS 
5000C  I A EDS  PBOH  22. 

???  IS  THIS  CORBECT  ???  (YES/NO) 


Figure  3.59  Query  -  Bearing/Hange  Ccnf iraation. 

The  fcllcwing  is  the  correct  response  to  this  query  as 
applicable. 

KE  —  YES  <cr>  or  NO  <cr> 

VB  —  "Affirmative"  or  "Negative" 

Should  a  mistake  occur  in  making  this  response  you  will  see 
the  following: 

PLEASE  ENT  EB  "YES"  OB  "NO" 

Simply  reenter  your  YES/NO  response.  If  you  enter  "YES," 
then  ycu  will  either  sequence  to  the  next  ship  requiring 
position  input,  or  if  no  more  ships  require  positions,  you 
mill  move  to  the  neit  section  of  -he  BUILD  module,  estab¬ 
lishing  the  Composite  Warfare  Commander  (cwc)  Organization. 
If  ycu  had  entered  SC  to  the  position  confirmation  query, 
then  the  query  sheen  in  Figure  3.55  would  again  be 
presented,  and  you  wculd  repeat  the  position  entry  sequence 
for  that  ship. 


(4 )  Quer?  Seg  uence  —  Cartesian  Coordinate 

Svst em.  In  response  to  the  query  shown  in 
figure  3.53,  if  you  desire  tc  input  the  positions  of  the 
battle  group  units  in  cartesian  coordinates,  then  you  would 
enter  the  following. 

KB  —  CARTESIAN  <cr> 

PR  —  "Cartesian  Coordinate  System" 

You  would  then  he  gueried  for  the  cartesian  positions  of 
each  ship  in  the  battle  group  (less  the  unit  at  "ZZ").  The 
format  fcr  the  specification  of  the  position  is  Quadrant, 
X-Cocrdinate,  Y-Cocrdinat e.  Each  of  these  entries  is 

separated  by  a  space,  as  shown  in  the  query  example.  The 
composition  of  the  query  is  shown  in  Figure  3.60. 


FOB  PAUL  F  FOSTER 

NEAT  IS  HER  POSITION  IN  CARTESIAN  COORDINATES  ??? 

(ENTER  AS  QUADRANT  (R,W,B,G),  SPACE,  X-POSITION, 
SPACE,  Y-POSITION) 

(E.G.  S  C30  090) 


figure  3.60  Query  -  cartesian  Position. 


To  demonstrate  the  correct  format  for  the  cartesian  position 
input,  let's  give  PA01  F  FOSTER  the  position  WHITE  15C  100. 
Particularly  when  entering  your  response  from  the  keyboard, 
it  is  iipcitant  to  conform  exactly  to  the  format  for  the 
response.  There  can  be  NO  extra  spaces.  When  making  the 
input  by  voice,  while  the  input  command  has  some  length, 
this  is  not  a  problem  when  you  follow  ohe  example. 

KB  —  W  150  100  <cr> 
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78  —  "Shite”  "One"  "Five"  "Zero"  "Space"  "One"  "Zero" 

"Zero"  "Carriage  Return" 

One  cf  the  first  things  that  the  system  checks  in  the  input 
is  that  the  quadrant  is  one  cf  the  four  options.  If  the 
guadrant  response  is  ether  that  B ,  W,  B,  or  G,  then  the 
warning  shewn  in  Figure  3.61  will  be  presented.  For 
example,  let’s  say  you  accidentally  entered  "K"  as  the  guad¬ 
rant  . 


YOU  HIVE  ENTERED  "K"  AS  THE  QUADRANT,  WHICH  IS  NOT  R, 
H,  B,  OB  G 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.61  BBBOB  -  Cartesian  Quadrant. 


when  ycu  continue,  ycu  will  be  presented  with  the  instruc¬ 
tion  shewn  in  Figure  3.62. 


PHASE 

REENTER  THE  POSITION: 

QUADRANT 

(R,W,B,G)  , 

SEACE, 

I-POSITION,  SPACE,  Y-PO 

SITION 

(E.G. 

R  300  200) 

***  PRESS  RETURN  TO 

CONTINUE 

*** 

Figure  3.62  EBBOB  -  Cartesian  Position  Entry. 


It  may  seem  like  overkill,  but  when  you  continue,  you  will 
again  be  presented  with  the  query  shown  in  Figure  3.60. 


You  can  than  reenter  jour  cartesian  position  for  the  unit  in 
question.  Cnee  the  position  has  been  entered  correctly,  the 
sjstea  vill  present  the  quadrant  and  X/Y  positions  back  to 
you  fer  confirmation.  This  display  is  shown  in  Figure 
3.63. 


THE  CARTESIAN  POSITION  OP  PAUL  P  FOSTER  IS:  8  150  100 
???  IS  THIS  CORRECT  ???  (YES/NO) 


figure  3.63  Query  -  Confirmation  of  Cartesian  Position. 


The  correct  response  to  this  query  would  be  "YES,"  as  this 
is  the  correct  position  for  FOSTER.  In  general,  the 

correct  response  to  this  query  would  be  as  shown  below,  as 
applicable. 

kb  —  YES  <cr>  or  NO  <cr> 

la  —  "Affirmative”  or  "Negative" 

If  you  enter  YES  to  the  guery  shown  in  Figure  3.63,  then  you 
will  be  asked  for  tie  position  of  the  next  ship  in  the 
tattle  group,  or  if  all  ships  have  been  assigned  positions, 
then  you  will  move  tc  the  next  phase  of  the  BUILD  module, 
establishing  the  Composite  Warfare  Commander  (CSC) 
Organization. 

f.  Establishing  the  Composite  Warfare  Commander 
(CMC)  Organization 

The  next  phase  in  the  initialization  of  a  battle 
group  database  is  the  establishment  of  the  CWC  organization. 
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The  information  shone  in  Figure  3.64  will  be  presented  to 
you  as  as  intord  ccticn. 


100  HILL  NOW  ASSIGN  NAMES  AND  EMBARKED  UNITS  FOR  EACH 
WARFARE  COMMANDER.  NAMES  CAN  BE  ENTERED  TO  A  MAXIMUM 
OE  25  CHARACTERS.  SOME  EXAMPLES  ARE  AS  FOLLOWS: 


CCMCARGRG  1 
COMDESRON  9 
CCMDES  EON  23 
CO,  PAOL  F  FOSTER 
CO,  ME  FRILL 


TOO  CAN  INCLODE  TEE  COMMAS,  HOWEVER  BE  CAREFUL  IF  TOO 
ARE  ENTERING  BT  VOICE  TO  FOILCW  THE  USER'S  MANUAL  NAME. 
IF  TEE  NAME  IS  NOT  IN  THE  USER'S  MANUAL,  THEN  MANUAL 
NAME  ENTET  WILL  BE  REQUIRED. 


Figure  3.64  Introduction  to  CHC  Organization  Determination. 


Within  this  section  of  the  BUILD  module,  you 
mill  identify  the  orcanizat iens  which  will  function  as  each 
cf  the  wazfare  commanders/coordinators,  and  identify  on 
which  ships  they  are  embarked.  Table  II  gives  examples  of 
the  types  cf  organizations  which  could  function  as  a  warfare 
commander  cr  coordinator.  The  table  additionally  shows  the 
acceptable  entries  fer  those  organizations. 


The  full  sccpe  of  the  sequence  establishing  the  CHC  organi¬ 
zation  is,  determination  of  the  organization  functioning  as 
the  warfare  commander/coordinator ,  determination  of  the  unit 
on  which  the  organization  is  embarked,  and  finally  a  display 
cf  the  full  CWC  Organization  for  your  confirmation.  For 
the  first  two  segments  of  the  sequence,  you  will  be  queried 
for  assignment  of  each  warfare  commander/coordinatcr  in  the 
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TABLE  II 


Keyboard/Vcice  Entries  for  Organizations 


KEYBOARD  ENTRY 

CCMCARG3U 

CCMCEDDESGRU 

CCMEESBCN 

CCHSCBBCN 

CC,  <ship  name> 


VOICE  ENTRY 

"Carrier  Group" 

"Cruiser  Destroyer  Group" 
"Destroyer  Squadron" 


"Destroyer  Squadron" 
"Submarine  Squadron" 
"Commanding  officer" 


"<ship  name>" 


order  presented  in  Table  III.  As  the  queries  are  iden¬ 
tical,  in  each  case,  only  one  example  (assignment  of  the 
Anti-Air  Warfare  Commander)  will  be  discussed. 


TABLE  III 

cue  Crganization  Components 

OFFICER  IN  TACTICAL  COMMAND  (OTC/AB) 
ANTI-AIR  WARFARE  COMMANDER  (AAWC) 
ANTI-SUBMARINE  WARFARE  COMMANDER  (ASWC) 
ANTI-SURFACE  WARFARE  COMMANDER  (ASUWQ 
AIR  ELEMENT  COORDINATOR  (AREC) 

LAMPS  ELEMENT  COORDINATOR  (LEC) 
SUBMARINE  ELEMENT  COORDINATOR  (SEC) 
ELECTRONIC  WARFARE  COORDINATOR  (EWC) 


(!)  Assignment  of  an  Organization.  The  query 
shown  in  Figure  3.65  is  representative  of  those  applying  tc 
all  warfare  commanders/ coordinators.  The  specific 
commanaer/ccordinator  will  be  identified  within  the  query. 
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Figure  3.65  Query  -  Anti-Air  Barf are  Commander. 


The  desired  response  is  one  of  the  organizations  shewn  in 
Table  II  followed  by  the  appropriate  number  or  ship  name,  as 
applicable.  For  the  purposes  of  our  example,  we  will 
assign  Commander  Cruiser  Destroyer  Group  Three  (CCMCRODESGRU 
3)  as  AAWC.  This  is  shown  in  the  following  example. 

KB  —  COMCRUDESGRO  3  <cr> 
va  —  “Cruiser  Destroyer  Grcup"  “Three"  “Carriage  Return" 

From  the  keyboard,  or  voice,  the  name  of  the  organization  is 
limited  tc  twenty-five  (25)  characters.  Should  an  error 
cccur  in  making  this  entry,  the  following  warning  will  be 
presented. 

EIEASE  REENTEE  THE  NAflE  CF  THE  ORGANIZATION 

This  would  be  followed  by  the  warfare  commander  query  to 
which  yee  are  responding.  Simply  reenter  your  response. 
Once  the  erganization  has  been  correctly  identified,  there 
are  several  sequence  options  which  may  take  place. 

If  this  is  the  first  time  you  have 
assigned  the  specified  organization  to  a  warfare  commander/ 
coordinator  role,  you  will  next  be  queried  for  identifica¬ 
tion  of  the  battle  grcup  unit  on  which  the 
ccmmandei/ccordinator  is  embarked.  This  is  covered  in  the 
next  section. 

If  the  organization  has  been  identified 
earlier  as  functioning  as  another  commandsr/coordinator ,  and 
the  unit  on  which  it  is  embarked  has  been  specified,  you 


will  skip  the  query  addressing  the  embarked  unit,  and  will 
sequence  tc  the  query  for  the  next  warfare  commander/ 
coordinator.  The  reason  for  this  is  that  the  system  will 
save  you  time  by  assigning  the  organization  on  which  ycu  are 
working  tc  the  unit  you  have  previously  identified  as 
embarking  it.  In  essence,  you  will  skip  the  embarcation 
query  for  any  subsequent  entry  of  the  same  organization. 

The  final  variation  in  which  you  can  find 
yourself  is  initiated  by  naming  a  ship's  Commanding  Officer 
as  a  ccmmander/coordinator.  It  would  be  redundant  to  guery 
you  about  on  which  ship  the  Commanding  Officer  of  CALIFORNIA 
is  embarked.  If  ycu  name  a  ship's  CO  as  the  organization 
for  a  queried  ccmmander/coordinator,  then  the  system  will 
automatically  embark  the  CO  cn  the  appropriate  ship.  You 
would  net  be  queried  for  an  embarked  unit,  and  would 
sequence  tc  the  query  for  identification  of  the  next  warfare 
commander/coordinator. 

(2)  Identifies tion  of  the  Embarked  Dnit .  Once 
the  organization  has  been  identified,  you  will  next  be 
queried  cn  which  unit  the  commander/coordinator  is  embarked. 
This,  of  course,  is  subject  to  the  variations  mentioned 
above  regarding  the  type  of  organization  entry  you  make. 
The  composition  cf  the  query  for  embarked  unit  is  shown  in 
Figure  3.66.  We  will  continue  with  the  development  of 
assigning  CCMCROEESGRU  3  as  AA8C. 

Onifcim  throughout  the  system,  whenever  a  requirement  for 
identification  of  a  ship  is  levied,  a  listing  of  the  avail¬ 
able  units  is  shown.  Remember  that  the  system  will  confirm 
your  entry  by  atttempting  to  match  it  to  one  of  the  ships 
shown  in  the  listing.  For  our  example,  we  will  embark 
COHCRCDESGRU  3  onboard  CALI FCRNIA.  This  entry  would  he  as 
follows. 


KB  —  CALIFORNIA  <cr> 
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FCB  CCMCRUDESGRU  3 

???  ON  WHICH  SBIF  IS  HE  EMEABKED  ??? 

CABL  VINSON  PAUL  F  FOSTEB  CALIFORNIA 

_ _ _ .  -  ■  _ _ - - - _ _ - _ - _ _ _ _ j 


Figure  3.66  Query  *  Embarked  Unit. 

VR  --  "CALIFORNIA" 

Should  an  error  occur  in  making  this  entry,  the  following 
earning  would  be  presented. 

PLEASE  ENSOBE  THAT  YCUS  ENTRY  EXACTLY  MATCHES  ONE  CF  THE 
SHIPS  LISTED. 

You  will  again  be  presented  with  the  quary  shown  in  Figure 
3.66,  and  can  reenter  your  response.  Once  the  embarked 
unit  has  been  correctly  identified,  you  will  sequence  tc  the 
next  warfare  commander/coordinator ,  for  identif icaticn  of 
the  orgarization  functioning  in  that  capacity.  If  all  of 
the  ccmmanders/coordinators  have  been  identified,  then  the 
entire  cue  Organization  will  be  presented  for  confirmation. 
This  is  covered  in  the  next  section. 

(3)  Confirmation  cj;  ths  CWC  Organization.  The 
information  shown  in  Figure  3.67  reflects  a  respresent ative 
CWC  organization  that  you  may  have  entered.  It  is  presented 
to  allow  ycu  to  make  any  corrections  prior  to  moving  on  tc 
the  next  phase  of  the  BUILD  module. 

When  ycu  continue,  by  entering  "RETURN ,"  you  would  see  the 
query  shewn  in  Figure  3.68,  asking  if  these  assignments  are 
correct. 
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HERE  IS  THE 

COMPOSITE  WARFARE  COMMANDER 

ORGANIZATION 

YCO  HAVE  ENTERED. 

CWC  CDR 

ORGANIZATION 

EMBARKED  IN 

OTC 

CCMCARGRU  1 

CARL  VINSCN 

A  AfiC 

CCMC RUDESGRU  3 

CALIFORNIA 

ASWC 

CCMDESRON  23 

CARL  VINSCN 

ASUSC 

CC,  PAUL  f  FOSTER 

PAUL  F  FOSTER 

A  EH 

CC,  CARL  VINSON 

CARL  VINSCN 

LEC 

CC,  PAUL  F  FOSTER 
CCMSUBRON  4 

PAUL  F  FOSTER 

SEC 

CARL  VINSCN 

ESC 

CCMCRUD  ESGBU  3 

CALIFORNIA 

***  PRESS  RETURN  TO  CONTINUE 

*** 

Figure  3.67 

Composite  Warfare  commander  Organization. 

f 

-  ■  -»  *  "  *  1111  11  11111  11  J 

k  HE  THESE  ASSIGNMENTS  CORRECT  ??? 

(YES/NO) 

Figure  3.68  every  --  C1C  Organization  Correct. 

The  response  to  this  query  is  YES/NO  as  appropriate.  If 
the  information  is  correct,  and  you  enter  YES,  then  you  will 
move  cn  to  the  next  phase  of  the  BUILD  module  in  initializa¬ 
tion  of  the  battle  group  database,  helicopter  embarcation 
status.  If  some  of  the  information  shown  in  Figure  3.67  is 
incorrect,  and  you  enter  NC„  then  the  view  shown  in  Figure 
3.69  will  be  presented. 


You  identify  the  entry  which  is  incorrect  by  specifying  the 
acronym  CTC,  AAWC,  ASWC,  etc.  Should  an  error  occur  in 
identifying  the  acronym,  the  following  will  be  presented. 

PLEASE  ENTER  THE  NAME  OF  THE  ACRONYM  EXACTLY  AS  INDICATED 
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???  WHICH  WARFARE  COMMANDER  (S)  IS/ARE  INCORRECT  ??? 

OTC  AAHC  ASWC  SEC 

IEC  ASCIWC  AREC  EWC 

(ENTER  TEE  APELICAELE  ACRONYM) 


Figure  3.69  ewe  Organization  Incorrect. 

You  «ill  then  see  the  query  for  identification  of  the 
warfare  commander  which  is  incorrect  (Figure  3.69).  Once 
the  ccmmander/cocrdinator  has  been  identified,  you  will  be 
asked  tc  specify  which  element,  organization,  embarked  unit, 
cr  both,  resuires  correction.  This  query  is  shewn  in 
Figure  3.70. 


???  WHICH  ENTRY  IS  INCORRECT:  ORGANIZATION 

EMBARKED  ON  IT 
BOTH 

(ENTER  TEE  APPLICABLE  PARAMETER) 


Figure  3.70  Query  -  Incorrect  Element  Identification. 


If,  i  r  example,  when  we  initially  identified  the  organiza¬ 
tion  functioning  as  AAWC,  we  bad  input  "CONRODESGRO  3,"  and 
we  new  wanted  to  correct  it,  we  would  enter  the  following  in 
rasponse  to  the  query  in  Figure  3.70. 

KE  --  ORGANIZATION  <cr> 

VR  --  "Organization” 
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Following  this  input,  you  would  be  presented  with  the  query 
shown  in  the  figure  representative  of  the  commander/ 
coordinator  with  which  you  are  working.  The  full  CKC  orga¬ 
nization,  as  shown  is  Figure  3.67,  will  always  be  shown  for 
confiraaticn  prior  to  allowing  you  to  move  to  the  next  phase 
of  the  BOIIC  module.  The  full  range  of  options  for  identi¬ 
fication  of  the  incorrect  element  is  shown  in  the  following 
example. 

KB  —  ORGANIZATION  <CT>  Cr  EMBARKED  UNIT  <cr>  cr 

BOTH  <cr> 

VR  —  "Organization"  or  "Embarked  Unit"  cr 

"Beth" 

Should  there  be  a  mistake  in  making  this  response,  then  the 
following  will  be  presented. 

PLEASE  ENTER  "ORGANIZATION,"  "EMBARKED  UNIT,"  OR  " EOTH.  " 

This  will  te  followed  by  the  query  shewn  in  Figure  3.70  , 
after  which  you  can  reenter  year  response. 

a.  Determination  of  Helicopter  Embarcation  Status 

The  next  and  final  phase  of  initializing  the 
battle  group  database  is  determination  of  the  helicopter 
embarcation  status  fer  those  ships  which  are  HELO  capable. 
If  ycu  had  to  manually  enter  the  capabilities  for  a  ship  not 
in  the  taster  database,  then  you  are  familiar  with  this 
input  sequence,  as  ycu  specified  whether  the  unit  was  HELO 
capable  as  well  as  whether  the  detachment  was  embarked. 
Ecr  those  units  whose  capabilities  were  automatically  input, 
you  will  te  initially  establishing  the  EMBARKED/NOT  EMBARKED 
capability.  For  these  ships  for  which  this  entry  had  been 
xada  manually,  you  will  be  reaffirming  the  currency  of  the 
embarcation  status.  The  composition  for  the  queries  is 
keyed  to  the  type  cf  HELO  capability  that  the  ship  has. 
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Aircraft  carriers  always  have  their  detachments  embarked  in 
the  master  database,  therefore,  you  will  not  be  queried  as 
to  their  enbarcation  status.  (You  will,  however,  te  able  to 
change  that  embarcaticn  status  in  the  STATUS  module,  if  you 
so  desire.)  Using  FAUL  F  FOSTER  as  an  example,  the  query 
is  shewn  in  Figure  3.71. 


???  DCES  PAUL  I  FOSTER  HAVE  HER 
ONBOARD  ??? 


LAMPS  DETACHMENT 


figure  3.71  COSBY  -  HELO  Eubarcation  Status. 


The  desired  response  to  this  query  is  "YES"  or  "NO."  The 
format  fer  the  correct  response  is  as  follows. 

kb  —  YES  <cr>  or  NO  <cr> 

VB  —  "Affirmative"  or  "Negative" 

This  query/response  sequence  will  continue  for  each  ship 
that  has  a  HELO  capability.  Should  there  be  an  error  in 
taking  this  response,  than  you  will  be  advised  to  "ENTER  YES 
CR  NC,"  after  which  ycu  can  reenter  your  response.  Once  the 
helicopter  embarcaticn  status  has  been  determined  fer  all 
HELO  capable  ships,  ycu  are  finished  with  initially  forming 
the  battle  group  database. 

2.  Completion  oj  Battle  Group  Database  Initialization 

After  the  helicopter  embarcaticn  status  had  been  determined, 
you  are  finished  with  initializing  the  battle  group  data¬ 
base.  As  was  mentioned  several  paragraphs  earlier,  the 
system  will  now  condcct  an  automatic  SAVE  of  the  information 
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you  have  entered.  Remember,  though,  that  this  inf crmation 
mill  be  erased  if  ycu  terminate  your  session  with  a  STOP 
command.  when  you  next  invoke  the  BUILD  module  from  the 
query  shewn  in  Figure  3.6,  you  will  have  the  capability  to 
INSERT  or  DELETE  a  unit,  or  REBUILD  the  entire  battle  group 
database.  The  information  shewn  in  Figure  3.7  2  (adjusted) 
represents  the  options  that  are  now  available  to  you  upon 
invoking  the  BUILD  module.  These  capabilities  will  covered 
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in  the  fcllcv-on  sections  of  BUILD  module  operations. 

3 .  INSERT  s  Unit  Into  the  Battle  Group  Database 

If  you  desire  to  INSERT  a  unit  into  the  battle  group 
database,  ycur  response  to  the  query  shown  in  Figure  3.72 
would  be  as  follows. 

KB  —  INSERT  <cr> 

VR  —  "Insert  a  Unit" 

The  first  presentation  will  be  a  query  for  the  name  of  the 
ship  you  desire  to  ISSEBT.  This  will  be  indicated  by  the 


*  BUILD  NODULE  OPTIONS  * 


INSERT  -  INSEET  &  UNIT  INTO  THE  BATTLE  GROUP 

DATABASE 

DELETE  -  DELETE  A  UNIT  FROM  THE  BATTLE  GROUP 

DATAEASE 

REECIIC  -  DELETES  ALL  THE  INFORMATION  CURRENTLY 

IN  USE  FOR  THE  BATTLE  GROUP  AND  ALLOWS 
YOU  TC  REBUILD  THE  ENTIRE  GROUP. 


???  WHAT  IS  YOUR  CHOICE  (INSERT,  DELETE,  REBUILD)  ??? 


Figure  3.72  BUILD  Nodule  Options. 
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appearance  cf  the  "SHIP  NINE  ?"  prompt  with  which  ycu  are 
faailiar.  Following  the  prompt,  you  should  enter  the  name 
cf  the  ship  in  question.  The  restrictions  on  the  format  of 
the  name  are  the  sane  as  we  have  discussed  before.  If  you 
need  icre  inforaation  cn  naae  formats,  refer  to  the  section 
in  BOILD  module  operations  covering  ship  naae  entry.  For 
cur  example  battle  gicup,  should  we  desire  to  add  OSS  KANSAS 
CITY  (AOB-3) ,  the  following  input  would  be  appropriate. 

KB  —  KANSAS  CITY  <cr> 

VR  —  "KANSAS  CITY" 

Should  there  be  an  error  in  making  this  response,  you  will 
be  asked  to  reenter  the  name  of  the  ship  you  desire  to 
INSERT.  Once  the  naae  has  been  correctly  input,  the  system 
will  reconfirm  with  ycu  the  spelling  of  your  entry.  This 
reccrf iraation  is  shewn  in  Figure  3.73. 


KANSAS  CITY  IS  THE  UNIT  YOO  DESIRE  TO  ENTER  (YES/NC) 


Figure  3.73  Confirmation  of  INSElTed  Ship's  Name. 


Had  we  accidentally  mis  polled  KANSAS  CITY,  then  the 
tispelled  name  would  have  appeared  in  the  query.  If  the 
name  is  correctly  spelled,  and  you  answered  "YES"  tc  the 
query,  the  master  database  will  be  searched  for  the  ship 
whose  name  you  have  entered.  If  located,  its  capability 
database  will  be  automatically  filed.  If  it  is  net  found 

in  the  master  database,  then  manual  entry  of  her  capabili¬ 
ties  will  be  required.  Manual  sntry  is  discussed  under 
Initializing  the  battle  group  database.  If  your  response 
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to  th«  confirmation  query  had  been  NO,  then  the  ’’SHIP  NAME 
?"  prompt  would  again  appear  and  you  could  reenter  the  name 
of  the  unit  you  desire  to  INSERT. 

Cnee  the  ship’s  capabilities  have  been  determined, 
either  automatically  cr  manually,  you  will  next  be  asked  for 
the  ship’s  position.  The  format  for  this  guery  is  depen¬ 
dent  upon  what  coordinate  system  you  specified  when  you 
initially  formed  the  battle  group.  The  composition  of  the 
guery  will  be  either  that  shown  in  Figure  3.55  or  Figure 
3.60.  If  you  require  more  detail  in  responding  to  these 
gueries,  refer  to  the  section  on  Polar  or  Cartesian  posi¬ 
tions  discussed  earlier.  After  determination  of  the  ship’s 
position,  you  will  be  asked  for  her  HELO  embarcation  status, 
if  she  is  HELO  capable.  Once  the  embarcation  status  has 
teen  determined,  you  will  be  presented  with  the  new  composi¬ 
tion  of  the  battle  greup.  This  presentation  is  shewn  in 
Figure  3.74. 


HERE  ARE  TEE  ONUS  IN  YOUR  BATTLE  GROUP 

CARL  VINSON  PAOL  F  FOSTER  CALIFORNIA 

KANSAS  CITY 

***  PRESS  RETURN  TC  CONTINUE  *** 

figure  3.74  lew  Battle  Group  Composition. 

When  ycu  continue,  ycu  will  be  advised  that  if  this  change 
to  the  tattle  group  composition  affects  the  ewe  organiza¬ 
tion,  ycu  can  make  the  required  correction  in  the  STATUS 
module.  The  composition  of  this  warning  is  shown  in  Figure 
3.75.  8hen  you  continue,  you  will  be  returned  to  the  MAIN 
module. 


NCTE  —  IP  THIS  CHANGE  AFFECTS  THE  CWC  ORGANIZATION, 
ICC  CAN  CHANGE  THE  ORGANIZATION  IN  THE  STATUS  MODULE 

***  PRESS  RETURN  TO  CONTINUE  *** 


figure  3.75  Naming  -  Inpact  of  Change  on  CWC  Organization. 

4.  DELETE  a  Unit  From  the  Battle  Group  Database 

If  you  desired  to  delete  a  unit  from  the  battle 
group  database,  you  would  malce  the  following  entry  in 
response  to  the  query  shown  in  Figure  3.72. 

KB  —  DELETE  <cr> 

¥R  —  "Delete  a  Unit" 

The  first  presentation  you  will  see  is  a  listing  of  the 
battle  group  as  it  now  exists.  If  you  now  include  the 

insertion  of  the  KANSAS  CITE  into  the  battle  group,  as  was 
done  in  the  INSERT  example,  the  composition  of  the  listing 
is  shewn  in  Figure  3. "6. 


TEE  BATTLE  GRCUP  CONSISTS  Cf: 

CARL  VINSON  PAUL  E  FOSTER  CALIFORNIA 

KANSAS  CITY 

x??  WHICH  UNIT  DO  YOU  DESIRE  TO  DELETE  ??? 


figure  3.76  DELETE  Cption  -  Current  Battle  Group  Listing. 


You  should  enter  the  name  cf  the  unit  exactly  as  shewn  in 
the  listing.  Shoulc  a  mechanical  error  (hitting  an 
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incorrect  execution  key)  occur  in  making  this  response,  you 
vill  see  the  following: 


PLEASE  ENTER  THE  NAME  OP  THE  UNIT  100  DESIRE  TO  DEIETE 

Ifter  this,  simply  reenter  the  name  of  the  unit.  If  you 
enter  the  name  of  a  unit  not  in  the  battle  group  database, 
then  the  following  warning  will  be  displayed. 

YOUR  ENTBI  CANNOT  EE  LOCATED  AMONG  THE  NAMES  OF  THE  EATTLE 
GROUP  UNITS.  PLEASE  CHECK  THE  SEELLING/FORMAT  AND  REENTER. 

***  PRESS  RETORN  TO  CONTINOE  *** 

When  ycu  continue,  the  guery  shown  in  Pigure  3.76  will  again 
be  presented,  and  ycu  can  reenter  your  response.  If  you 
desired  to  delete  the  unit  designated  as  "ZZ,"  you  will  be 
removing  the  reference  position  for  the  graphics  portions  of 
the  system.  If  the  "ZZ "  unit  is  deleted,  you  will  be 

advised  that  the  Battle  Group  position  information  must  be 
reinitialized.  This  procedure  starts  with  the  query  shown 
in  Pigure  3.51,  which  is  where  you  will  be  cycled. 

5.  REBUILD  the  Eat  tie  Group  Database 

If  you  desire  to  form  a  new  battle  group  during  a 
decision  support  system  session,  you  would  enter  the 
following  in  response  to  the  query  shown  in  Pigure  3.72. 

KB  —  BEEUILD  <cr> 

7R  —  "Rebuild  Option" 

Bhen  ycu  select  the  BEBUILD  option,  you  have  indicated  that 
you  want  tc  erase  tie  current  battle  group  database,  and 
reconstruct  a  new  one.  To  ensure  that  you  recognize  the 
ramif icaticns  of  making  this  selection,  the  warning  shown  in 
Figure  3.77  will  be  presented. 
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IOC  HAVE  OPTED  TO  EBASE  THE  BATTLE  GROUP  DATABASE 
AND  EEEOILD  IT. 

???  ABE  IOU  SOBE  THIS  IS  WHAT  YOU  WANT  TO  DO  ??? 
(IES/NO) 


Figure  3.77  WABIIHG  -  Battle  Group  Database  To  Be  Erased. 

The  desired  response  to  this  query  is  IES  or  NO.  If  you 
enter  "YES,"  then  you  will  repeat  the  sequences  discussed 
under  Initializing  the  Battle  Group  Database.  If  you  enter 
NO  tc  this  query,  then  you  will  be  returned  to  the  MAIN 
module,  and  the  current  battle  group  database  will  be 
retained.  Should  an  error  occur  in  making  this  response, 
you  will  be  asked  tc  reenter  your  YES/NO  response. 

H.  STATES  BODULE  OPEEATIOVS 

The  STATUS  module  basically  facilitates  data  manipula¬ 
tion  within  the  battle  group  database.  In  this  module  you 
can  DISPLAY  various  capabilities  of  the  battle  group,  as 
well  as  DISELAY  the  entire  database  for  a  particular  unit. 
It  would  he  in  this  icdule,  also,  that  you  could  CHANGE  any 
element  cf  the  unit's  database,  CHANGE  force  unit  positions, 
cr  make  a  CHANGE  to  the  CWC  Organization.  Finally,  the 
STATUS  module  allows  you  tc  enter  a  field  of  BEMABKS  about 
any  unit,  and  have  these  remarks  aad9  a  part  of  that  unit's 
database.  The  STATUS  module  is  invoked  from  the  query 
shown  in  Figure  3.6  as  shown  below. 

KB  —  STATUS  <cr> 

7H  —  "Status  Module" 
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The  first  tine  you  invoke  this  module,  you  will  be  presented 
with  the  explanation  cf  module  capabilities  shown  in  Figure 
3.78  (adjusted)  . 


BATTLE  GROUP  ASSET  MANAGEMENT 
DECISION  SUEEORT  SYSTEM 

*  STATUS  MODULE  * 

IBIS  MODULE  WILL  ALLOW  Y CU  TO  PERFORM  THREE  MAJOR 
FUNCTIONS.  FIRST,  YOU  CAN  "DISPLAY"  UNIT  DATABASE, 
FCRCE  INFORMATION  JHELO  CAPABILITIES,  TASS  CAPABILI¬ 
TIES,  POSITIONS,  MISSIONS,  AS  WELL  AS  TOMAHAW K/H AFPCCN 
CAPABILITIES.  SECCND.  YCU  CAN  CHANGE  DATA  FOR  A  PAR¬ 
TICULAR  UNIT,  FORCE  POSITIONS.  OR  AN  ELEMENT  OF  THE 
CMC  ORGANIZATION.  FINALLY,  YOU  CAN  ADD  REMARKS  (UP  TO 
25  CHARACTERS)  FOR  ANY  UNIT. 


***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.78  STATUS  Module  Capabilities. 

This  module  does  not  utilize  any  computer  graphics  capa¬ 
bilities,  therefore,  all  displays  will  be  made  on  your 
termiral  screen.  When  you  continue,  you  will  be  shown  the 
module  options,  and  asked  if  you  desire  to  review  the 
command  format  for  any  option.  This  view  is  shown  in 
Figure  3.79. 


Each  cf  tfcese  options,  with  their  respective  commands,  will 
be  discussed  in  succeeding  portions  of  this  section  of  the 
manual.  If,  in  response  to  the  guery  shown  in  Figure  3.79, 
you  dc  net  desire  to  review  the  specific  command  for  a  capa¬ 
bility  ycu  wish  to  utilize,  you  would  enter  CARRIAGE  RETURN, 
as  shown  in  Figure  2.80.  This  input  will  generate  the 
query  shewn  in  Figure  3.81,  asking  you  to  input  your  desired 
module  command.  Should  an  error  occur  in  making  this,  or 
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STATUS  MCDU IE  OPTIONS 
DISPLAY  CHANGE  REMARKS 


IF  YOU  WOULD  LIKE  10  REVIEW  THE  FORMATS  FOR  THE  STATUS 
MODULE  COMMANDS,  ENTER  THE  AEPROPRIT AT E  OPTION  (DIS¬ 
PLAY,  CHANGE.  REMARKS),  OR  "EXIT"  IF  YOU  WANT  TO  LEAVE 
THE  MCDUIE,  &THERWISE  &RESS  THE  CARRIAGE  RETURN  TO 
CONTINUE. 


Figure  3.19  STATUS  Module  Options. 

any  response  to  the  query  shown  in  Figure  3.79,  then  the 
following  warning  will  be  presented. 

PLEASE  ENTER  YOUR  SEIECTION  EXACTLY  AS  PER  THE  INSTRUCTIONS 

***  PRESS  RETURN  TO  CONTINUE  *** 

When  you  enter  "RETURN,"  as  shown  in  Figure  3.80,  you  will 
again  te  presented  with  the  view  shown  in  Figure  3.79,  and 
can  reenter  your  response. 


Make  the  follcwinc  entries,  as  appropriate, 
*  -  -  a  »»fcEigKN"  command. 


to  effect 


a  "CARRIAGE  RETURN"  or  a 


KB  —  <cr> 

v R  —  "Carriage  Return" 


Figure  3.80  Entry  of  "CABBIAGE  BETURN"  or  "HETUHN". 
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1 


PLEASE  ENTER  TOUR  STATUS  MODULE  COMMAND 


figure  3.81  STATUS  Module  Coeeand  Query. 

and  break  the  a  up  into  tvo  or  three  segments  depending  on 
the  first  word  of  the  command.  The  key  positions  for  the 
break  up  are  the  spaces  between  the  words  of  the  command, 
ihen  entering  from  the  keyboard,  be  sure  that  if  the  example 
shows  a  space,  you  enter  the  space.  Otherwise,  the  system 
will  not  recognize  your  command  segments.  The  examples  for 
entry  by  voice  already  allow  for  the  "space"  requirement  in 
most  cases.  When  they  don*t,  the  examples  will  show 
"Space"  in  the  VR  command  string.  Before  we  discuss  the 
functions  of  each  module  cption,  it  would  be  prudent  to 
review  seme  of  the  pitfalls  you  may  encounter  in  entering 
the  required  commands. 

1  •  Ecdule  £cmma£d  Form  frt  fyrors 

As  we  have  already  discussed,  this  module  looks  at 
all  commands  in  terns  of  a  specific  number  of  segments. 
The  command  you  will  enter  will  be  broken  down  into  segments 
with  the  spaces  serving  as  the  break  points.  The  system 
will  ther  look  at  each  segment  individually,  ?  -  d  in  a  tree 
like  fashion,  evaluate  succeeding  segments.  For  example, 
there  are  three  possible  entries  which  could  comprise  the 
first  segment,  DISPIAY,  CHANGE,  or  REMARKS.  Once  this 
segment  has  been  evaluated,  the  second  segment  is  identi¬ 
fied.  If  the  DISPIAY  option  were  selected,  and  identified 
as  the  first  command  segment,  then  tha  system  would  lock  for 
UNIT,  FCBCE,  or  COEEAND,  as  the  second  segment,  as  these 
three  entries  are  the  ONLY  ones  which  could  legally  follow  a 
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EISPLIY  option  command.  This  process  would  continue  into 
evaluation  of  the  third  segment,  if  the  particular  command 
entry  required  one.  For  your  purposes,  you  need  only  think 
of  the  module  option  commands  as  complete  phrases  in  a 
required  format.  Tc  avoid  any  confusion,  the  next  sections 
will  discuss  the  warnings  which  will  be  system  generated  in 
response  to  an  inability  tc  recognize  a  particular  segment 
of  a  command.  These  section  are  here,  not  to  intimidate 
you,  tut  rather  to  give  you  seme  reference  to  the  specific 
cause  cf  an  error. 

a.  Error  --  First  Command  Segment 

Once  you  have  entered  your  module  option 
command,  the  system  will  lock  for  the  first  segment  (or 
word).  As  you  have  seen,  there  are  only  three  possible 
choices  for  this  segment,  as  far  as  the  system  is  concerned, 
DISPLAY,  CHANGE,  or  REMARKS.  If  the  system  cannot  match 
the  first  segment  of  your  command  to  one  of  these  words, 
then  the  information  shown  in  Figure  3.82  will  be  presented. 


YCDB  CCMHAND  CANNCT  BE  ASSOCIATED  WITH  "DISPLAY”, 
"CHANGE",  OR  "REMARKS".  YOU  WILL  3E  ASKED  TO  REENTEB 
THE  CCNMAND. 


**♦  pa  ESS  RETURN  TO  CONTINUE  *** 


Figure  3.82  EBBOB  -  First  Segment. 

You  would  continue  ty  entering  "CARRIAGE  RETURN,"  as  shewn 
in  Figure  3.80.  Following  this  entry,  you  woul^  be 
returned  tc  the  view  shown  in  Figure  3.79,  and  resume  the 
query/respense  sequence. 
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t.  Error  in  Second  Segment 

The  system  will  anticipate  the  possible  choices 
for  a  second  segment,  based  cn  the  identity  of  the  first 
segment.  For  the  DISPLAY  option,  there  are,  again,  three 
possible  words  which  could  be  second  segments,  FORCE,  UNIT, 
cr  COMMAND.  If  one  of  these  three  words  cannct  be  matched 
to  the  seccnd  segment  in  your  command,  the  warning  shewn  in 
Figure  3.83  will  be  presented. 


IE  F  HEM  YOU  WISHED  DISPLAYED  IS  NOT  "UNIT ”,  "FORCE", 
OB  "COMMAND" .  YOO  WILL  HATE  TO  REENTER  YOUR  COMMAND. 

**♦  pfiSSS  RETD  BN  TO  CONTINUE  *** 


Figure  3.83  ERBGB  —  DISPLAY  Option  Second  Segment. 


Ycu  would  continue  by  entering  CARRIAGE  RETURN,  shewn  in 
Figure  3.80,  and  you  would  be  returned  to  the  query  shewn  in 
Figure  3.79  where  ycu  can  reinitiate  the  query/response 
sequence. 

If  the  first  segment  of  your  module  option 
command  were  CHANGE,  the  system  would  look  for  either  FCRCE , 
UNIT,  cr  COMMAND  as  the  second  segment.  If  none  of  these 
words  could  be  matched  to  the  second  segment  cf  your 
command,  the  information  shown  in  Figure  3.84  would  be 
displayed. 


You  would  continue  by  entering  "CARRIAGE  RETURN,"  as  shewn 
in  Figure  3.80,  and  you  would  be  returned  to  the  query  shewn 
in  Figure  3.79,  from  which  you  can  reinitiate  the  query/ 
response  sequence. 
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TH£  EIBMENT  ICO  WISH  TO  CHANGE  IS  NOT  "FORCE",  "COM¬ 
MAND",  OB  "ON IT" .  IOO  WILI  HAVE  TO  REENTER  THE  COM- 
M  ARE. 


***  PRESS  BETOBN  TO  CONTINUE  *♦* 


Figure  3*84  EBSOB  —  CB11GB  Option  Second  Segment. 

If  the  first  segment  of  your  module  option 
command  mere  REMARKS ,  the  system  would  look  for  a  ship  name 
as  the  second  segment.  If  there  was  an  error  in  recog¬ 
nizing  your  entry  as  the  name  of  a  ship  in  the  battle  group, 
you  would  be  simply  asked  tc  reenter  the  name  of  the  ship  in 
question,  and  would  not  be  returned  to  the  the  query  shewn 
in  Figure  3.79. 

c.  Error  in  Third  Command  Segment 

(7)  M  DISPLAY  FORCE"  Command.  If  you  desired 
to  display  a  capability  of  the  force  (DISPLAT  FORCE) ,  then 
the  system  would  lock  for  one  of  the  following  words  to 
identify  the  capability  you  desira.  These  words  are, 
MISSICNS,  POSITIONS,  BELO,  HARPOON,  TASS,  and  TOMAHAWK.  If 
none  of  these  words  can  be  matched  to  the  third  segment  of 
your  command,  the  information  shown  in  Figure  3.85  will  be 
displayed. 


You  should  make  the  following  entry,  in  response  tc  the 
query  shewn  in  Figure  3.85,  tc  review  the  command  formats. 

KB  —  FORMAT  <cr> 

VB  —  "Review  Formats" 
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XOCB  CC BEARD  HAS  BCT  BEES  BATCHED  TO  THE  AVAILABLE  OP¬ 
TICS'  .  TOO  SILL  EAVE  TO  BEENTER  IT.  SHOULD  YOO  DE- 
SIBE  TO  BEVIES  THE  COHHAHD  FORMAT,  ESTER  "FORH  AT" , 
OIBERSISE,  IF  SOT,  PBESS  CASBIAGE  BETORS. 


|  Figare  3.8$  1110 ■  —  Coaaand  Incorrect. 

yea  dc  net  desire  to  r«ri«v  the  cosmand  formats,  then  you 
should  enter  "CARRIAGE  BETOES,"  as  shove  in  Figure  3.80,  and 
I  the  query  shown  in  Figure  3.81  will  be  displayed. 

(2)  Mil"  CQii&ad.  If  you  desired  to 

display  the  database  for  a  unit  (DISPLAY  OMIT),  the  system 
^  will  anticipate  the  naae  of  a  ship  in  the  battle  group  as 

the  third  segaent.  It  yonr  entry  cannot  be  matched  tc  one 
cf  the  battle  group  cnits,  you  will  be  asked  to  reenter  the 
naae  of  the  unit  in  question. 

i  (3|  "DISFlir  CCagAMD"  Coaaand.  There  is  no 

third  word  in  the  ccaaand  to  display  the  CSC  Organization, 
therefore,  the  systea  does  not  look  for  one. 

(4)  "£JBlSfiE  IORCE"  Command.  The  only  force 
element  which  can  be  changed  is  POSITIONS,  therefore,  the 
systea  will  look  for  POSITIONS  as  the  third  word  in  this 
ccaaand.  if  the  third  word  of  your  command  cannot  be 
matched  to  POSITIONS,  the  information  displayed  in  Figure 
3.86  will  be  displayed. 

To  continue,  enter  "CARRIAGE  EETORN,"  as  shown  in  Figure 
3.80,  and  you  will  be  returned  to  the  query  in  Figure  3.79, 
from  which  you  can  reinitiate  the  query/response  sequence. 
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10  0  CAN  CNLY  CHANGE  FORCE  POSITIONS.  PLEASE  REENTER 
YCDR  COMMAND. 


***  PRESS  RETORN  10  CONTINUE  *** 


Figure  3.86  ERROR  —  CHARGE  FORCE  Option  -  Third  Segment. 

(5)  "CHARGE  OgJT"  Command.  The  third  segaent 
in  the  CBANGE  ONIT  ccaaand  is  the  name  of  the  unit  whose 
database  you  desire  tc  change.  If  the  system  cannot  match 
the  name  in  your  command  to  one  of  the  battle  group  units, 
as  you  have  seen  befcre,  you  will  be  asked  to  reenter  the 
name  cf  the  unit  concerned. 

(6)  "CHANGE  COMMAND"  Command.  There  is  not 
third  segment  to  the  CHANGE  COMMAND  command,  therefore,  the 
system  will  not  look  for  one. 


2.  STATUS  Module  zz  Display  Option 

The  commands  required  to  initiate  the  DISPLAY  features  cf 
this  module  are  shown  in  Figure  3.87  (adjusted).  To  have 
this  view  presented,  you  would  enter  the  following  in 
response  tc  the  query  shown  in  Figure  3.79. 

KB  —  DISPLAY  <cr> 

7R  —  "Display"  "Carriage  Return" 

Ycu  would  enter  "RETURN,"  as  shown  in  Figure  3.80  to 
continue.  When  ycu  continue,  you  will  be  asked  to  input 
the  module  command  ycu  desire.  This  query  is  shown  in 
Figure  3.81.  The  fact  that  you  have  just  reviewed  the 
"DISPLAY"  commands  dees  NO£  restrict  you  to  just  "DISPLAY" 
commands.  At  this  point,  you  can  designate  any  of  the 
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"DISPLAY"  COMMANDS: 

DISPLAY  UNIT  (UNIT  NAME)  DISPLAYS  UNIT  DATAEASE 

(ENTER  QUIT  NAME  WITHOUT  PABENS 

E.G.  DISPLAY  UNIT  MEHRILI) 


DISPLAY  FORCE  HEIO 

MISSION 
POSITIONS 
H AEPOON 

TCEAHABK 

TASS 

DISPLAY  COMMAND 

***  PBESS  BETOEN 


DISPLAYS  HELO  CAPAELE 
UNITS 

DISPLAYS  UNIT  MISSIONS 
DISPLAYS  UNIT  POSITIONS 
DISPLAYS  HARPOON 
CAPABLE  UNITS 
DISPLAYS  TOMAHAVK 
CAPABLE  UNITS 
DISPLAYS  TASS  CAPABLE 
UNITS 


DISPLAYS  CWC  ORGANI¬ 
ZATION 

TO  CONTINUE  *** 


t 


I 


» 


Figure  3.87  STATUS  Module  —  DISPLAY  Commands.  > 

module  options.  Be  will  next  look  at  each  of  the  "DISPLAY" 
features. 

a.  Displaying  a  Unit’s  Database  * 

This  feature  of  the  STATUS  module  will  allow  you  to  view  the 

entire  datatase  for  the  unit  you  designate.  In  order  to 

display  the  unit’s  database,  you  would  enter  the  following  » 

in  response  to  the  guery  shown  in  Figure  3.81. 

KB  —  DISPLAY  UNIT  PAUL  F  FOSTER  <cr>  or 
DISPLAY  UNIT  CARL  VINSON  <cr> 

VR  —  "Display"  "Unit"  "PAUL  F  FOSTER"  or  * 

"Display"  "Unit"  "CARL  VINSON" 


I 
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The  same  requirements  for  ship  names  apply  here  as  you  have 
seen  earlier.  You  could  use  the  shorter  name  forms  (e.g. 
FOS1EB  fcr  PAUL  F  FCSTEE  or  VINSON  for  CARL  VINSCN)  in 
either  input  case.  The  system  will  segment  the  command  in 
the  following  order,  "DISPLAY,"  "UNIT,"  »<ship  name>."  As 
you  have  already  seen,  the  DSS  will  attempt  to  match  the 
name  cf  the  unit  you  have  entered  with  those  in  the  battle 
group  database.  If  there  is  no  match  made,  you  will  be 
asked  to  reenter  the  name  of  the  ship  ONLY,  not  the  entire 
command.  The  format  for  the  database  display  is  shown  in 
Table  IV.  In  the  display  for  an  actual  ship,  the  headings 
shown  in  Table  IV,  as  well  as  the  ship's  capabilities  would 
be  shown  together.  PAUL  F  FOSTER  is  utilized  as  an 
example.  Some  comments  about  the  rationale  for  the  format 
cf  this  display  are  appropriate.  In  order  to  accomodate 
the  amount  cf  data  in  the  ship's  database,  and  still  display 
it  on  one  view,  the  resultant  format  is  somewhat  ccngest-d. 
Incorporating  the  information  this  way,  however,  affords  the 
user  the  advantage  cf  having  everything  readily  displayed, 
as  opposed  to  sequencing  through  different  views.  The  data 
is  organized  into  categories  as  a  method  of  partitioning  the 
information  shown.  It  is  the  opinion  of  the  author  that 
once  familiar  with  the  infcrmation  format,  the  user  will 
feel  comfortable  with  the  display. 
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TABLE  IV 

Ship* s  Database  Display  Format 


VO 

a  co 

ITSO 

WWW 

IflvOO' 

2BX 

s 

1  1  *“ 

O  1  1 

coco 

coca  • 

z 

Qi  a  as 

ox 

o 

cococ* 

QH 

am  as 

VN.x 

WH 

Q 

vOCM  t  a 

**\ 

w 

Qi  W 

w 

O' 

wwz 

H 

1  OSH 

*5 

a  w 

Ml 

w 

— o  n 

O  1  wm 

1 

► 

ohw 

asm 

X  1  1 

w 

W  04 

CQ 

|  z  >< 

u 

CO  W 

13 

a 

W— JX 

—  u 

MM 

asasz  i 

co  a  co 

wau 

ww 

a 

4*4  Z 

1 

U«HQ 

WCOH 

woo 

9C3COW 

as'— 

HOO 

X 

3UWW 

s 

CO  OS  HU 

a 

KtOHO< 

cow 

a 

CO  COW 

H 

SC  CO 

o 

co 

HM4 

Ml 

ww 

as 

z 

X  X 

H 

hIUXS 

H 

o 

1 

X 

axwa 

z 

XO<4£ 

WO 

a 

H 

wan 

ZCJ 

wco 

EhSSM 

o 

HN 

XOW 

2W 

ox 

NU» 

as 

i 

O 

aw 

l  w 

co 

W  1 

CO 

-J*4 

o 

O 

H 

zx 

w  w 

a 

COE-4 

CO  z 

-8 

Ml  W 

—  o 

as 

w 

x  z 

H 

o 

Cm 

X 

as 

X 

Ml 

CO  1 

U4 

IOM 

US  C/l 

aa 

u 

H  a 

W 

w 

MM 

Ml  X 

wm 

wcie 

XUS 

as 

W 

Ml  | 

P“  z 

04  CA 

M 

>U 

1  w 

X4 

X  as 

Wx 

xax 

MIX 

CO  CO 

<y> 

X 

h  aw 

MX 

O  W 

O  1 

\ 

W  X 

W 

1*4 

aw  co 

* 

vox 

-r*o 

1 

| 

l  as  mu 

MS 

CNfcM 

m 

MU 

CO  *4 

w 

C/I4- 

XCN 

«-*«© 

04  1 

O 

a 

X'-' 

H 

w  Win 

CO  1 

as 

X  1 

* 

x  cn 

HZ 

a  a» 

H 

z 

wa 

WO 

«c  i  wo 

zwmx 

z 

ox 

CO 

zcn  i 

HW 

04  O' 

WWlOH 

o 

H 

X 

\ 

XX 

wz 

CU  1  W 

u 

vOH 

w 

1  S  X 

4H 

wo 

1  —'COW 

w 

H 

cnx 

o<a 

Oh* 

— >  0*H 

Q 

H 

CO 

— .  w 

MIX 

aszco 

HWCOIH 

z 

us 

X 

H  1  H 

oo 

a««co 

# 

WO\W 

Ml 

1  Ml 

CO 

w  co 

o 

N8H  1 

04 03  Z  04 

CO  04 

04XX 

w 

sc  so 

C/I 

^'flWW 

w 

a  mi 

CO 

•M4I/1 

MM 

HU  SC 

w 

xz  U 

z 

Ha 

z 

H 

* 

H« 

xux© 

O 

UO  1 

Ml 

a 

o 

WXW 

OiX 

w  ww 

CO 

ISU  CN 

SO 

«B 

MM 

wxz 

o 

UH 

cohuwh 

z 

co  «m 

x 

wo 

Ml 

MX  Ml 

VI 

UW 

waxw 

MM 

UM  | 

o 

u 

MM 

X  w 

w 

HW 

HOW  co 

CO 

CBB5ZO 

u 

WH 

z 

X2< 

X 

WX 

-cos  ceo 

WHOM 

XW 

Max 

HU 

UiOHUlll 

* 

WWXCO 

* 

SCO 

•* 

SUCH 

■w 

MM  W 

* 

* 

* 


« 

a 

Z 

w 

H 

z 

o 

o 


o 

H 


OS 

3 

H 

W 

OS 

X 

(O 

w 

w 

W 


p 


f 


w 


146 


» 


There  arc  two  caveats  regarding  the  display  of  a 
unit  database.  First,  if  the  ship  to  be  displayed  is  ar. 
aircraft  carrier,  the  GROUP  COMMANDER  entry  will  be  replaced 
with  CARRIER  GROUP.  Second,  the  format  of  the  position 
information  is  keyed  to  the  type  of  coordinate  system  chosen 
(polar  or  cartesian).  Finally,  unless  you  enter  them, 
there  are  nc  stored  REMARKS  fcr  a  ship.  Therefore,  the 
field  following  that  heading  may  be  blank.  When  you  enter 
"CARRIAGE  RETURN,"  following  this  display,  you  will  be 
returned  to  the  query  shown  in  Figure  3.79. 

t.  Display  Force  Helicopter  Capabilities 

This  feature  of  the  STATUS  module  will  allow  you 
to  observe  the  helicopter  capable  units  in  the  battle  group 
and  determine  their  detachment  EMBARK/NOT  EMBARKED  status. 
You  invoke  this  capability  by  entering  the  following  in 
response  to  the  query  shown  in  Figure  3.81. 

KB  —  DISPLAY  FORCE  HELO  <cr> 

DR  —  "Display"  "Battle  Group"  "Helicopter  Units" 

This  command  would  generate  a  display  on  the  terminal 
screen,  of  the  battle  group  units,  their  helicopter  capa¬ 
bility,  and  the  emtarcaticn  status  of  the  detachment,  if 
applicable.  Obviously,  if  the  ship  has  nc  capability,  the 
status  wculd  be  NOT  EMBARKED.  The  format  for  this  presen¬ 
tation,  with  some  representative  data,  is  shown  in  Figure 
3.88. 

Within  the  composition  of  Figure  3.88,  you  will 
notice  the  capability/status  entry  "NO  STATUS."  This  means 
that  there  is  no  database  entry  for  these  capabilities. 
The  normal  manner  in  which  this  could  occur  would  have  come 
from  manual  database  entry  in  the  BUILD  module.  when  you 
are  inputting  the  ship's  capability  database  manually,  you 
can  skip  seme  of  the  required  information  from  the 

147 


1 


*  BATTLE  6 BO OP  HEIO  CAPABLE  UNITS  * 


EBIT  NAME 


CAPABILITY 


EM  BARKED 


PAUL  F  PCSTBB 
CALIFCBNIA 
CABL  VINSON 
KANSAS  CITY 
GUAM 


LAMPS  DETACHMENT 
NOT  CAPAELE 
SH-3  DETACHMENT 
CH-46  DETACHMENT 
NO  STATUS 


EMBARKED 
NOT  EMBARKED 
EMBARKED 
EMBARKED 
NO  STATUS 


***  PRESS  RETURN  TO  CONTINUE  *** 


Elgar*  3.88  STATUS  Bodule  —  Display  of  Helo  Capable  Units. 


capability  menus.  The  appearance  of  "NO  STATUS"  indicates 
that  this  has,  in  fact,  happened.  To  correct  this  situ¬ 
ation,  ycu  would  utilize  the  CHANGE  capability  of  the  STATUS 
■odule  tc  input  the  appropriate  capability,  a  topic  which  is 
forthcoming.  When  ycu  are  through  with  reviewing  the  heli¬ 
copter  capability  information  and  continue,  you  will  be 
returned  to  the  presentation  shown  in  Figure  3.79. 

c.  Display  cf  Force  Positions 

This  feature  of  the  STATUS  module  allows  ycu  to 
display,  on  the  terminal  screen,  the  positions  of  the  ships 
in  the  battle  group.  You  would  invoice  this  capability  by 
entering  the  following  in  response  to  the  query  shewn  in 
Figure  3.81. 


KB  — 


DISPLAY  FORCE  POSITIONS 


<cr> 


VR  —  "Display"  "Eattle  Group"  "Positions" 

The  specific  display  which  wculd  result  from  this  command 
depends  cn  the  type  cf  coordinate  system  in  use.  If  the 
polar  coordinate  system  is  currently  being  utilized,  then 
the  Figure  3.89  shows  a  representative  display  of  the 
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information  you  will  observe.  If  the  cartesian  coordinate 
systea  is  being  utilized,  then  the  presentation  shown  in 
Figure  3.90  is  representative  of  the  information  you  will 

observe. 


BATTLE  GBOUP  POSITIONS 
(POLAR) 

ID 

NANS 

3  NG 

BNG 

1 

PAUL  F  FOSTER 

90 

50000 

2 

CAHL  VINSON 

0 

0 

3 

CALIFCBNIA 

***  PE  ESS  RETURN  TO 

0 

CONTINUE*** 

100000 

Figure  3.89  Battle  Group  Positions  --  Polar. 


Let's  exaaine  the  information  in  the  presentation  shewn  in 
Figure  3.89.  You  should  first  notice  that  any  leading 
zeros  are  emitted.  Therefore,  "09 0"  would  be  displayed 
"90,"  and  "000"  would  be  displayed  "0."  Such  is  the  case 
with  the  positions  of  FOSTEB  and  CABL  VINSON,  respectively. 
The  positions  shown  in  the  presentation  for  the  polar  coor¬ 
dinate  system  show  bearings  and  ranges  from  "ZZ."  You  can 
see,  then,  froa  the  inforaation  in  Figure  3.89,  that  CARL 
VI  NS  CM  is  at  "ZZ,"  as  her  bearing  and  range  are  both  ZEBO 
(0)  .  Froa  this  display,  you  can  determine  the  following: 
PAUL  F  FOSTEB  is  bearing  090  degrees  true,  range  50,000 
yards  from  "ZZ,"  CAEI  VINSCN  is  at  "ZZ,"  and  CALIFORNIA  is 
tearing  000  degrees  true,  range  100,000  yards  from  "ZZ." 
In  all  cases,  you  could  substitute  CARL  VINSON  for  any  "ZZ" 
desigraticn.  The  cartesian  positions  ars  displayed  as 
shown  next. 
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BATHE  GE COP  POSITIONS 
(C A  ETESIAN) 


II 

UNIT 

QUAD 

X-POSIT 

Y-POSIT 

1 

PAUL  F  FCSTER 

W 

100 

90 

2 

CARL  VINSCN 

G 

20 

10 

3 

CALIFORNIA 

B 

100 

50 

***  PRESS  RETURN  TO  CONTINUE  *** 


figure  3.90  Battle  Group  Positions  —  Cartesian. 

As  we  saw  in  the  example  of  polar  positions, 
there  are  NO  leading  zeros  shewn  in  the  numbers.  You  could 
derive  the  following  from  the  information  shown  in  Figure 
3.90.  PAUL  F  FOSTER  is  in  the  WHITE  quadrant,  with 

x-positicn  100  and  y-position  90.  CARL  VINSON  is  in  the 
GREEN  quadrant,  with  x- position  20  and  y-position  10. 
CALIFORNIA  is  in  the  ELUE  quadrant,  with  x-positicn  100  and 
y-positicn  50.  Unlike  the  example  for  polar  positions,  it 
is  net  clear  from  the  information  shown  in  Figure  3.90, 
which  unit  is  at  "2Z."  If  you  were  using  the  cartesian 
coordinate  system,  and  desired  to  determine  which  unit  is  at 
"ZZ,"  you  should  move  to  the  SENSOR  module  and  display  the 
battle  group  positions  on  the  graphics  monitor.  This  would 
give  you  a  tetter  feel  for  the  "relative”  positioning  cf  the 
units. 

To  continue,  after  viewing  the  battle  greup 
positions,  you  would  enter  the  command  shown  in  Figure  3.80. 
So  dcing  will  return  you  to  the  query  shown  in  Figure  3.79. 

d.  Display  cf  Force  Missions 

This  feature  of  the  STATUS  module  allows  you  to 
view  the  currant  primary  and  secondary  missions  of  the 
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battle  group  units.  Aside  from  the  informational  value  of 
this  display,  you  can  get  the  feel  for  a  key  element  cf  the 
communications  makeup  of  the  battle  group.  The  primary  and 
secondary  missions  for  each  unit  serve  as  the  keys  to 
assigning  those  units  to  the  various  battle  group  communica¬ 
tions  nets.  Therefore,  as  a  unit  has  a  primary  mission  of 
AAR,  and  a  secondary  mission  of  ASR,  she  vould  be  included 
in  all  AIR  and  ASR  circuits,  as  veil  as  circuits  designated 
for  the  Fcrce  as  a  vhole.  To  display  the  battle  grcup 
missions,  make  the  following  entry  in  response  to  the  query 
shown  in  Figure  3.79. 

KE  —  DISPLAY  FORCE  MISSIONS  <cr> 

VB  —  "Display"  "Battle  Grcup"  "Mission  Areas" 

Figure  3.91  (adjusted)  shows  the  composition  of  the  tattle 
group  Missions  display.  It  is  essentially  in  two  groups  of 
columns  shewing  the  ship  names,  primary  and  secondary 
missions  in  each  of  the  two  cclumns. 


*  BATTLE  G  ECUE  MISSIONS  * 


NAME 

PRI 

SEC 

PAD!  F  FOSTEE 

ASR 

ASU 

CARL  VINSON 

STB 

AAR 

CALIFORNIA 

AAR 

ASU 

***  PRESS  RETORN  TO  CONTINUE  *** 


Figure  3.91  Battle  Group  Missions. 


The  representation  shown  ir  this  figure  is  straightfovard. 
Table  V  shews  the  definitions  cf  the  various  mission  area 
abbreviations. 
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T1BLI  T 
Hiss Ion  Areas 


Abbreviation 

NNN 

AAW 

ASH 

ASO 

AMW 

STR 

LOG 


Mission  Area 

No  Mission 
Anti-Air  Warfare 
Anti-submarinq  Warfare 
Anti-Surface  warfare 
Amphibious  Warfare  (NGFS) 
Strike  Warfare 
Logistic  Support 


You  can  return  to  the  module  menu  (Figure  3.79),  after 
viewing  the  mission  informations  in  the  display  of  Figure 

3.91,  by  entering  "RE1UBN, M  as  shown  in  Figure  3.80. 

€.  Display  cf  Force  HIBEOON  Capable  Units 

This  feature  of  the  STATUS  module  allows  you  to 
display  the  names  of  the  units  in  the  battle  group  which 
have  a  HABPCON  capability.  To  initiate  this  feature,  you 
would  enter  the  following  command  in  response  to  the  query 
shown  in  Figure  3.79. 

KB  —  DISPLAY  FORCE  HARPOON  <cr> 

VR  —  "Display”  "Battle  Group"  "HARPOON  Weapons" 

This  ccmsand  would  result  in  the  display  shown  in  Figure 

3.92.  Ihe  composition  of  this  display  is  straightfcward  in 
that  ctly  the  names  cf  the  HARPOON  capable  units  are  shewn. 


If  there  were  no  HARECON  capable  units  in  the  battle  group, 
you  wculd  see  the  following  on  the  terminal  screen. 

*****************  none  FOUND  ***************** 
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*  BATTLE  CBCOP  HABPCCN  CAPABLE  UNITS* 


<ship  name> 

<ship  rame> 

<ship  name> 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.92  Harpoon  Capable  Units. 

Following  this  display,  you  can  continue,  and  return  tc  the 
eodule  menu,  by  entering  CARRIAGE  RETURN,  as  shown  in  Figure 
3.80. 

f.  Display  ci  Force  TOHAHAfiK  Capable  Units 

Similar  tc  the  previous  section,  this  feature  of 
the  STATUS  module  allows  you  to  display  the  names  of  the 
units  in  the  battle  group  which  have  a  TOMAHAWK  weapons 
capability.  To  display  this  information,  you  would  make 
the  fcllcwirg  response  to  the  query  shown  in  Figure  3.79. 

KE  —  DISPLAY  FOBCE  TOMAHAWK  <cr> 

VB  —  "Display"  "Battle  Group"  "TOMAHAWK  Weapons" 

The  display  you  would  initiate  in  making  this  response  is 
shown  in  Figure  3.93.  As  ycu  saw  with  the  HARPOCN  capa¬ 
bility  display,  only  the  names  of  the  ships  with  this  capa¬ 
bility  are  shown. 


If  there  had  been  nc  units  in  the  battle  group  with  this 
capability,  then  the  following  would  be  displayed. 

*****************  NONE  FOUND  ***************** 

When  ycu  are  finished  with  this  information,  you  can  return 
tc  the  rcdule  menu  by  entering  "RETURN,"  as  described  in 
Figure  3.80. 
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*  BATTLE  6 1; COP  TOMAHAWK  CAPABLE  ONUS  * 

<ship  name> 

<ship  nase> 

<shfp  naae> 

*♦*  PRESS  RETURN  10  CONTINUE  *♦* 


figure  3.93  TOMAHAWK  Capable  Onits. 

g.  Display  cf  Force  TASS  Capable  Units 

This  capatility  of  the  STATUS  module  allows  you 
tc  display  the  names  cf  the  units  in  the  battle  group  with  a 
TASS  capability,  alcng  with  the  name  of  the  specific  model 
cf  the  eguipaent  onboard.  To  initiate  this  feature,  you 
would  enter  the  following  in  response  to  the  query  shown  in 
Figure  3.79. 

KE  —  DISPLAY  FORCE  TASS  <cr> 

VR  --  "Display"  "Battle  Group"  "TASS  Systems" 

The  information  shown  in  Figure  3.94  is  representative  of 
the  display  you  would  observe  after  making  this  entry. 


*  BATTLE  GROUP  TASS  CAPABLE  UNITS  * 

EAUL  F  FOSTER  AN/SQR-19  (IMPROVED  TACTASS) 

ALBERT  DAVID  AN/SQR-18  (TACTASS) 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.94  TASS  Capable  Onits. 


154 


If  no  units  with  a  IASS  capability  were  found  to  be  in  the 
battle  group,  the  following  would  be  displayed  on  the 
terainal  screen. 

44444*444*4444444  liCNE  FOUND  *444444444*44*444 

When  you  are  through  reviewing  the  information  shown  in 
Figure  3.94,  you  can  return  to  the  module  menu  by  entering 
"CAR El AG  I  RETURN,"  as  shown  in  Figure  3.80. 

h.  Display  Composite  iarfare  Commander  Organization 

This  feature  of the  STATUS  module  allows  you  to 
display  the  current  CWC  organization.  This  display  is 
initiated  by  making  the  following  entry  in  response  tc  the 
query  shown  in  Figure  3.79. 

KB  —  DISPLAY  COBH  AND  <cr> 

VE  --  "Display  "  "CWC  Organization" 

As  a  result  of  making  this  entry,  you  would  see  the  informa¬ 
tion  shown  in  Figure  3.95,  which  is  representative  of  a 
normal  CIC  organization. 

»hen  you  are  through  with  this  information,  and  are  ready  to 
return  tc  the  module  menu,  you  should  enter  CARRIAGE  BETUHN, 
as  shewn  in  Figure  3.80. 

3.  §11123  JlS&llS  Cringe  QRt^on 

The  formats  for  the  CHANGE  commands  are  shown  in 
Figure  3.96.  These  commands  can  be  displayed  by  entering 
the  following  in  response  tc  the  query  shown  in  Figure  3.79. 

FB  —  CHANGE  <cr> 

VB  —  "Change  Database"  "Carriage  Return" 


I 

! 

i 

i 

HEBE  IS  A  LISI  OF  THE  COMFCSITE  WARFARE  COMMANDER  OR 


G1N1Z ATICN  TOO  HAVE 

ENTERED. 

CSC  CEB 

ORGANIZATION 

EM EARN  ED  IN 

OTC 

COMC  ROD  ESGRU  3 

NIMITZ 

AAWC 

CO,  GRIDLEI 
COMDESFCN  23 

GRIDLEY 

ASNC 

MERRILL 

ASUWC 

CO,  MERRILL 

MERRILL 

ASEC 

CO,  NIMITZ 

NIMITZ 

LEC 

CO.  PAOL  F  FOSTER 
COMSUBECN  4 

PAOL  F  FCSTEB 

SEC 

NIMITZ 

EWC 

CO,  GRIDLEY 

GRIDLEY 

***  PRESS 

RETORN  TO  CONTINUE 

*** 

Figure  3.95  Composite  Warfare  Coeeander  Organization. 


"  ‘ 

"CHANGE"  COMMANDS: 

CHANCE  (UNIT  NAME) 

CHANGE  DATABASE  FOR  A  UNIT 

(ENTER  UNIT  NAME  WITHOUT 
A  MENU  WILL  EE  PROVIDED 
ELEMENT) 

PARENS  E.  G.  CHANGE  NIMITZ. 

FOR  SELECTION  OF  SPECIFIC 

CHANGE  FORCE  POSITIONS 

CHANGES  POSITIONS  FOR  All 
UNITS 

CHANGE  COMMAND 

CHANGE  CWC  ORGANIZATION 

***  PRESS  RETURN 

TO  CONTINUE  *** 

Figure  3.96  STATUS  Module  —  CHANGE  Commands. 

When  ready,  you  would  continue  by  entering  CARRIAGE  RETURN, 
as  3hcwn  in  Figure  3.£0.  Ycu  will  then  be  presented  with 
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the  query  fcr  your  STATUS  module  command#  as  shown  in  Figure 
3.81.  Even  though  you  have  just  reviewed  the  CHANGE 
command  formats#  ycu  are  not  limited  to  making  a  CHANGE 
command,  and  are  free  to  utilize  either  DISPLAY#  CHANGE#  or 
6EM ARKS.  He  will  look  at  each  of  the  CHANGE  command 
cpticns  individually. 

a.  Changing  a  Unit's  Database 

If  you  desire  to  change  s  unit's  database,  you 
should  make  the  following  entry  in  response  to  the  query 
shown  in  Figure  3.81.  As  an  example#  we  have  decided  to 
CHANGE  the  FOSTEH'S  database. 

KE  —  CHANGE  ONIT  PAUL  F  FOSTER  <cr> 

PR  —  "Change  Database"  "Onit"  "PAUL  F  FOSTER" 

In  order  to  identify  the  specific  capability  in  the  FOSTER'S 
database  you  desire  tc  change#  ycu  will  be  presented  with  a 
menu  listirg  the  titles  of  the  capabilities  in  the  database. 
This  menu  is  shown  in  Figure  3.97. 

As  a  point  of  interest,  the  capabilities  listed 
in  Figure  3.97  show  tte  elements  of  the  master  database  that 
are  stcred  for  each  unit,  with  the  exception  of  the  avail¬ 
able  OEF/BF  radios,  addressed  in  the  COMMS  module.  If  the 
unit  was  not  in  the  master  database#  these  items  were  the 
capabilities  which  ycu  input  manually  for  that  unit.  The 
cperaticrs  involved  with  changing  a  unit's  database  will 
utilize  the  same  menus  which  you  utilized  in  performing  this 
manual  entry.  They  are  all  shewn  in  the  section  under  the 
BUILD  8CB0LE  OPEBATICBS  heading#  which  covers  manual  entry 
of  the  database.  Here  is  hew  it  will  work. 

The  desired  response  to  the  menu  shown  in  Figure 
3.97  would  be  the  number  corresponding  to  the  capability 
which  ycu  desire  to  change  in  the  unit's  database.  There 
are  generally  twe  categories  of  option.  First,  you  can 
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*  DATABASE  ENTS Y  OPTIONS  * 


I  i  * 
1! 


BOIL  NUMBER 
GECUP  COMMANDEB 
SCCADEON  COMMA NEEfi 
PRIMARY  MISSILE  SYSTEM 
SECCNCABY  MISSIIE  SYSTEM 
BAFFOCN  CAPABILITY 
PBIMABY  AIB  SEARCH  BADAB 
SECONDARY  AIR  SEARCH 
PACAB 

SUEEACE  SEARCH  SADAR 
PBIMABY  PIBE  CCSTROL 
BADAB 

SECONDARY  FIRE  CCNTROI 
FAIAR 

NO.  CF  UHF  RADIOS  ONBD 
NO.  OE  HF  RADIOS  ONBD 
SATCOM  CAPABILITY 
GUN  WEAPONS  SYSTEM  ONBD 


16  PHALANX  CAPABILITY 

17  TOMAHA8K  CAPABILITY 

18  HELO  CAPABILITY 

19  HELO  CAPABILITY  CNBD 

20  SONAB  SYSTEM  ONBD 

21  I  YDS  CAPABILITY  CNBD 

22  TASS  SYSTEM  ONBD 

23  A SB  SOCKET  CAPABILITY 

24  TORPEDO  CAPABILITY 

25  MAXIMUM  SPEED 

26  SLQ-32  CAPABILITY 

27  PRIMARY  MISSION  AREA 

28  SECONDARY  MISSION  AHEA 

29  ALL  OF  THE  ABOVE 


Figure  3.97  Quit  Database  Capability  options. 


specify  the  specific  capability  you  desire  to  change 
(numbers  1  -  28),  CB,  you  can  change,  or  more  exactly, 

rewrite,  the  unit's  entire  database.  In  the  former 
categcry,  you  would  be  queried  for  the  capability  you 
specify,  with  the  option  menu  corresponding  to  that  capa¬ 
bility,  and  then  returned  to  the  STATUS  module.  In  the 
latter  case,  you  would  be  recompiling  the  unit's  database, 
and  would  therefore,  sequence  through  ALL  of  the  capability 
menus,  and  then  returned  to  the  STATUS  module.  After  you 
have  completed  with  the  option  you  select,  you  will  be 
queried  as  to  whether  you  desire  to  make  this/these  chances 
a  permanent  part  of  the  master  database.  The  intent  of 

this  feature  is  to  allow  you  to  maintain  a  real  time  data¬ 
base,  reflective  of  the  unit's  capabilities,  NOW.  Mere 
often  than  not,  these  changes  would  be  of  a  temporary 
nature.  Should  however,  the  change(s)  you  make  be  of  a 
permanent  nature,  then  you  could  premanently  change  the 
master  database.  It  is  your  choice. 
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If  you  desired  to  change  the  PRIMARY  MISSII2 
SYSTEM  capability  of  the  unit  you  designated  in  response  to 
the  guery  shown  in  Figure  3.81,  you  would  make  the  following 
entry  frca  the  senu. 

KB  —  4  <cr> 

VR  —  "Four"  "Carriage  Return" 

Entering  this  command  woud  result  in  the  display  of  the 
HI  SSI  IE  SYSTEM  CPTICKS  menu  shown  in  Figure  3.25.  You 
would  designate  the  systea  the  unit  now  has  by  indicating 
the  apprcpriate  systea  from  the  aenu.  (This  is  cowered,  in 
detail,  under  BOILD  ECDULE  OPERATIONS.)  Table  VI  can  serve 
as  a  guick  reference  to  the  aenus  which  will  appear  when  you 
designate  a  particular  capability  change. 

Once  you  have  aade  your  change,  the  guery  shewn 
in  Figure  3.98  will  be  presented,  as  has  already  been 
discussed.  If  you  enter  YES  to  this  guery,  the  change  you 
have  just  made  will  become  a  part  of  the  master  database. 
If  you  enter  NO  to  this  query,  the  change  will  be  retained 
in  the  battle  group  database  ONLY. 


???  HC  OLE  YOU  LIKE  TO  HAKE  TBIS  CHANGE  TO  BE  PERMA¬ 
NENTLY  MADE  TO  THE  MASTER  DATABASE  ??? 

(YES/NO) 

Figure  3.98  Query  —  Bake  a  Capability  change  Peraanent. 

As  a  review,  the  format  for  this  response  is  shown  in  the 
following  example. 

KB  —  YES  <cr>  or  NO  <cr> 

IB  —  "Affirmative"  or  "Negative" 


TIBI I  f I 

Reference  of  Database  Capabilities  vs.  Option  Menus 


Capability 
BOLL  NUMBER 

group  commander 

SQUADRON  COMMANDER 
ERI  MARY  MISSILE  SYSTEM 
SECONDARY  MISSILE  SYSTEM 
HARPOON  CAPABILITY 
PRIMARY  AIR  SEARCH  RADAR 
SECONDARY  AIR  SEARCH  RADAR 
SURFACE  SEARCH  RADAR 
PRIMARY  FIRE  CONTROL  RADAR 
SECONDARY  EIRE  CONTROL  RADAR 
SO.  OE  UHF  RADIOS  ONBOARD 
NO.  Of  HF  RADIOS  ONBOARD 
SATCOE  CAPABILITY 
GUN  WEAPONS  SYSTEM  CAPABILITY 
PHALANX  CAPABILITY 
TOMAHAWK  CAPABILITY 
HELO  CAPABILITY 
EELO  CAPABILITY  ONBOARD 

SONAR  SYSTEM  ONBOARD 
IVDS  SYSTEM  ONBOARD 
TASS  SYSTEM  CNBOARD 
ASW  ROCKET  CAPABILITY 
TORPEDO  CAPABILITY 
MAXIMUM  SPEED 
SLQ-3 2  CAPABILITY 
PRIMARY  MISSION  AREA 
SECONDARY  MISSION  AREA 
ALL  OF  THE  ABOVE 


Option  Menu 


19 

23 

24 

25 

25 

26 
27 
27 

29 

30 

30 

31 

32 

34 

35 

36 

37 

38 

HELC 


Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Based  on 
Type 

Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
Figure  3. 
All  Menus 


t.  Changing  Force  Positions 

The  only  "Force"  elements  you  can  change  are  the 
positions  of  the  units.  If  you  desire  to  change  the  posi¬ 
tions  of  the  units  in  the  force,  you  would  make  the 
following  entry  in  response  tc  the  query  shown  in  Figure 
3.81  . 

KB  —  CHANGE  FORCE  POSITIONS  <cr> 

VR  —  "Change  Database"  "Eattle  Group"  "Positions" 
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The  first  view  that  will  be  presented  in  response  to  this 
entry  is  either  that  shown  in  Figure  3.89  (if  POLAR  coordi¬ 
nate  systea  is  in  use),  or  Figure  3.90  (if  CARTESIAN  coordi¬ 
nate  systea  is  in  use).  This  view  will  display  the 
positions  of  the  units  in  the  battle  group  as  they  currently 
exist  in  the  battle  group  database.  You  will  next  be 
gueried  regarding  what  position  information  you  desire  to 
CHANGE.  This  is  shewn  in  Figure  3.99. 


IF  JCC  SCOLD  UKE  TO  REV  A  ME  ZZ,  COORDINATE  SYSTEM,  AND 
UNIT'S  ECSITIONS ,  ENTER  "0",  OTHERWISE,  TO  CHANGE  A 
PARTICULAR  UNIT'S  POSITION,  ENTER  THE  ID  NUMBER  CO¬ 
RRESPONDING  TO  THE  UNIT. 


Figuxe  3.99  Query  —  Change  to  Battle  Group  Positions. 


The  desired  response  to  this  query  is  similar  to  others  you 
have  tade  requiring  the  entry  of  a  number  from  a  menu.  If 
you  enter  ZERO  (0)  tc  this  query,  you  will  repeat  the  query 
sequence  which  was  used  in  the  BUILD  module  to  initially 
establish  the  battle  group  positions.  The  first  view  you 
will  see  is  that  shown  in  Figure  3.51,  asking  for  the  iden¬ 
tity  of  the  unit  at  "ZZ."  This  will  be  followed  by 
queries  for  identification  of  coordinate  system,  and  posi¬ 
tions  of  each  unit  in  the  battle  group.  (These  sequences  are 
covered  in  detail  in  the  section  on  BUILD  MODULE 
OPERATIONS. ) 

If  you  desire  to  change  only  the  position  of  a 
particular  unit,  you  would  enter  the  number  corresponding  to 
that  unit,  from  the  query  shown  in  Figure  3.89,  or  Figure 
3.90.  You  would  then  begin  the  query  sequence  fer  either 
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fdar  cr  cartesian  position  determination,  as  appropriate, 
with  the  views  shown  in  Figure  3.55,  or  Figure  3.60,  respec¬ 
tively.  Once  completed,  irrespective  of  the  option  chosen 
(all  cr  individual  unit),  you  will  be  returned  to  the  STATUS 
nodule  menu  (Figure  3.79). 

c.  Changing  the  CWC  Organization 

If  ycu  desire  to  change  all  or  part  of  the  CWC 
crgacizaticnal  structure,  you  would  make  the  following 
response  to  the  guery  shown  in  Figure  3.81. 

KB  —  CHANGE  COMMAND  <cr> 

?B  —  "Change  Database"  "CWC  Organization" 

Cn  aaking  this  response,  ycu  will  be  presented  with  a 
display  cf  the  current  CWC  Organization,  an  example  of  which 
is  shewn  in  Figure  3.67.  When  you  continue  by  entering 
CARRIAGE  RETURN,  as  shown  in  Figure  3.80,  you  will  be  asked 
if  those  assignments  are  correct.  This  query  is  shown  in 
Figure  3.6e.  Based  on  your  response  to  this  query 
(XES/NO)  ,  you  will  follow  the  query  sequences  previously 
discussed  in  the  BOIIE  module,  for  making  corrections  to  the 
CMC  Organization.  If  you  need  to  review  these  sequences, 
you  should  refer  to  the  "List  of  Figures"  for  the  title  of 
the  view/query  composition  you  desire.  When  ycu  have 
completed  making  charges  to  the  CWC  Organization,  you  will 
be  returned  to  the  STATUS  module  menu  (Figure  3.79). 

4.  aiJSS  Nodule  -=  BEKABKS  Option 

This  feature  of  the  STATUS  module  allows  you  to 
enter  descriptive  remarks  to-  be  included,  and  displayed, 
with  a  particular  unit's  database.  The  format  for  the 
REMARKS  command  is  shewn  in  Figure  3.100.  The  display  of 
the  command  format  is  obtained  by  making  the  following  entry 
in  response  to  the  query  shown  in  Figure  3.79. 


KB 

VR 


REMARKS  <cr> 

"REMARKS"  “Carriage  Return" 


" REMARKS"  COMMANDS: 

REMARKS  (UNIT  NAME)  ENTER  REMARKS  FOR  A  UNIT 

(ENTER  TBE  NAME  WITHOUT  PARENS,  E.G. 

REMARKS  JOHN  YOUNG) 


Figure  3.100  Status  Module  —  REMARKS  Command. 


The  fcraat  cf  the  command  is  straightfoward,  "REMARKS"  is 
always  followed  by  the  name  of  a  ship  in  the  battle  group. 
When  you  continue,  by  entering  CARRIAGE  RETURN,  as  shewn  in 
Figure  3.80,  you  will  be  presented  with  the  query  shown  in 
Figure  3.101.  As  an  example,  if  you  wanted  tc  enter 
remarks  for  CARL  VINSON,  the  following  would  te  your 
response  to  the  query  shown  in  Figure  3.81. 

KE  —  REMARKS  CARL  VINSON  <cr>  or 

REMARKS  VI  NSC N  <cr> 

VB  —  "Remarks"  "CARL  VINSON"  or 

"Remarks"  "VINSON" 

lour  entry  would  be  followed  with  the  query  for  the  remarks, 
which  is  shewn  in  Figure  3.101. 

REMARKS  can  ON LI  be  entered  from  the  KEYBOARD.  The 

language  flexibility  for  voice  input  restricts  input  of 
ether  than  system  commands.  The  fora  of  your  REMARKS  can 
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KB 

VR 


REMARKS  <cr> 

"REMARK S"  "Carriage  Return" 


"REMARKS"  COMMANDS: 

REMARKS  (UNIT  NAME)  ENTER  REMARKS  FOR  A  ONIT 

(ENTER  THE  NAME  WITHOUT  FARENS,  E.G. 

REMARKS  JOHN  YOUNG) 


Figure  3.100  Status  Module  —  REMARKS  Command. 


The  format  cf  the  command  is  straightfoward,  "REMARKS"  is 
always  followed  by  the  name  of  a  ship  in  the  battle  group. 
When  you  continue,  by  entering  CARRIAGE  RETURN,  as  shewn  in 
Figure  3.80,  you  will  be  presented  with  the  query  shown  in 
Eigure  2.101.  As  an  example,  if  you  wanted  to  enter 
remarks  for  CARL  VINSON,  the  following  would  te  your 
response  tc  the  query  shown  in  Figure  3.81. 

KE  —  REMARKS  CARL  VINSON  <cr>  or 

REMARKS  VI  NSC N  <cr> 

VB  —  "Remarks"  "CARL  VINSON"  or 

"Remarks"  "VINSON" 

Your  entry  would  be  followed  with  the  query  for  the  remarks, 
which  is  shewn  in  Figure  3.101. 

REMARKS  can  ONLY  be  entered  from  the  KEYBOARD.  The 

language  flexibility  for  voice  input  restricts  input  of 
ether  than  system  commands.  The  form  of  your  REMARKS  can 
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1 


REMARKS  FOB  CARL  VINSON 

100  CAN  INTER  OP  TC  25  CHARACTERS  OF  REMARKS.  PLEASE 
CONFINE  YOUR  REMARKS  TO  THE  FOLLOWING  BOONDARIES. 

I  I 

V  V 

(area  for  remarks) 


j 


Figure  3.101  BEB&RKS  Input. 

take  cn  anything  ycu  desire  (e.g.  Embarked  Commander, 
Capability  Impairment,  Schedule,  etc.)  ,  provided  the  field 
of  the  statement  is  within  the  boundaries  shown  in  the 
query.  Should  you  exceed  the  confines  of  the  boundaries, 
the  information  to  the  right  cf  the  right  guide  arrow  will 
not  be  read  into  the  system.  Once  you  have  entered  the 
remarks,  they  will  become  a  permanent  part  of  that  unit's 
database,  and  will  be  included  in  the  database  display 
invoked  with  the  "DISPLAY  UNIT"  command.  Once  the  remarks 
have  teen  entered,  ycu  will  be  returned  to  the  module  menu 
(Figure  3.79). 

1.  CC SMS  MODULE  OPERATIONS 

This  feature  of  the  DSS  basically  allows  you  to  dc  two 
things.  First,  you  can  maintain  the  numbers  of  "Available" 
UHF/BE  radics  onboard  each  battle  group  unit.  The  second 
function  of  this  module  is  to  allow  you  the  opportunity  to 
display  the  composition  of  a  battle  group  communications 
net.  Ihe  display  cf  the  communications  net  requires  that 
you  have  a  graphics  capability.  If  you  do  not  have  one, 
you  must  restrict  ycur  use  of  this  module  to  managing  the 
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numbers  cf  available  radios.  You  would  invoke  the  COHNS 
module,  from  the  query  shown  in  Figure  3.6,  by  making  ■‘■he 
follcwing  entry. 

KE  —  CONNS  <cr> 

V B  —  "Cobbs  Nodule" 

this  ccmaand  will  cause  the  CCHNS  module  master  menu  to  be 
presented  on  the  terminal  screen.  The  format  of  this  menu 
is  shewn  in  Figure  3.102. 


*  EATT1E  GROUP  ASSET  NANAGENENT  * 

*  DECISION  SUPPORT  SYSTEH  * 

*  COHNS  NODULE  * 

IN  THIS  NODULE,  YOU  HAVE  THE  FOLLOWING  GENERAL 
CPIICNS: 


1  —  CHANGE  THE  NUNBER  OF  AVAILABLE  RADIOS  ONBOARD  A 

CNIT 

2  —  DISPLAY  THE  PARTICIPANTS  IN  A  BATTLE  GROUP  RADIC 

NET 

3  —  FETUBN  TO  THE  NAIN  NODULE 


(SELECT  CNE  OF  THE  ABOVE  (1,  2,  OR  3)) 


Figure  3.102  COBBS  Bodule  Options  Nenu. 


The  correct  response  to  this  query  is  the  number  corre¬ 
sponding  tc  the  option  you  desire.  If  you  desired  to 

display  the  participants  of  a  radio  net,  the  following  is  an 
example  cf  a  correct  entry. 

KB  —  2  <cr> 

Vp  --  "Two"  "Carriage  Return" 
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If  an  error  vere  to  cccur  in  caking  this  response,  you  Mould 
be  siiply  directed  tc  reenter  your  response  (1,  2,  cr3). 
lie  will  next  look  at  each  of  the  available  nodule  options. 

1.  CCHfiS  Module  —  Change  the  liumbgr  of  Available 

The  aim  of  this  feature  of  the  COMM 5  module  is  to 
allow  ycu  tc  maintain  a  real  time  estimate  of  the  numbers  of 
available  UHF/HF  radios  onboard  the  units  in  the  battle 
group.  The  intent  is  then  to  compare  these  numbers  with 
the  numbers  of  installed  radios  on  the  ships.  The  query 
sequences  associated  with  the  determination  of  either  UHF  or 
BF  available  radios  will  be  discussed  individually.  In 
respcrse  to  the  query  shown  in  Figure  3.102,  you  would  make 
the  following  entry  tc  invoke  this  module  feature. 

KB  —  1  <cr> 
ve  —  "One"  "Carriage  Return" 

The  next  query  that  wll  be  presented  will  be  to  identify  the 
unit  tc  which  this  change  will  apply.  The  format  for  this 
query,  with  a  representative  composition  of  ships,  is  shewn 
in  Figure  3.103. 


?  FOR  WHICH  BATTLE  GROUP  UNIT  WILL  THIS  CHANGE  APPLY  ? 
CARL  VINSON  PAUL  F  FOSTER  CALIFORNIA 


Figure  3.103  Query  —  Unit  those  Radios  are  to  be  Changed. 


The  entry  of  the  name  of  the  unit  must  match  the 
rame  cf  one  of  those  ships  in  the  list  following  the  query. 
The  system  will  check  your  entry  against  the  list,  and  if 


there  is  no  match,  you  will  be  asked  to  reenter  the  name  of 
the  applicable  unit.  The  next  query  will  address  whether 
you  desire  to  ADD  or  DELETE  either  a  OHF  or  HF  radio.  The 
fornat  for  this  query  is  shown  in  Figure  3.104,  and  for 
example,  suppose  you  wanted  to  change  the  number  of  radios 
cn  CALIFCENIA. 


FOB  CALIFORNIA 

WHICH  OF  THE  FOLLOWING  OPTIONS  WOULD  TOO  LIKE  TO  USE 

1  —  ADD  AN  AVAILABLE  UHF  RADIO 

2  —  DELETE  AN  AVAILABLE  UHF  RADIO 

3  —  ADD  AN  AVAILABLE  HF  RADIO 

4  —  DELETE  AN  AVAILABLE  HF  RADIO 

(ENTER  1,2,  3,  CE  4) 


Figure  3.104  Query  —  ADD  or  DELETE  a  OHI/HF  Radio. 


The  desired  response  to  this  query  is  straightfoward. 
These  options  will  allow  the  change  of  only  one  (1)  radio  at 
a  time.  Additionally,  the  system  will  check  the  change  you 
are  taking  to  ensure  two  things.  First,  you  cannot  increase 
the  nusber  cf  available  radios  beyond  the  database  number  of 
installed  radios  of  any  type.  Second,  you  cannot  decrease 
the  numbers  of  available  radios  below  zero  (0) .  The 
controlling  limits  are  determined  by  the  numbers  of  UHF  and 
HF  radios  in  the  database.  If  those  numbers  are  incorrect, 
or  there  has  been  a  change  to  them,  you  can  input  that 
change  in  the  STATUS  module.  if  need  be,  refer  tc  the 
appropriate  topic  in  that  module  to  effect  a  change,  if 
required.  You  can  also  view  the  number  of  installed  radios 


onboard  a  unit  by  displaying  its  database.  This  is  dene  in 
the  STATUS  nodule  as  veil.  Each  tine  you  attenpt  to  change 
the  nuaber  of  radios  onboard  a  unit,  you  will  see  a  summary 
of  the  current  database  regarding  the  installed  and  avail¬ 
able  OHF  and  HF,  after  each  entry. 

If  there  is  a  checking  problem  with  the  onboard 
numbers,  one  of  the  earnings  shown  in  Figure  3.105  will  be 
presented,  as  appropriate. 


CALIFORNIA  ALREADY  HAS  ALL  HER  UHF/HF  RADIOS  AVAILABLE 

(If, the  number  of  available  radios  equals  the  nuaber 
of  installed  radios,  and  you  attempt  to  add  a  radio) 

CALIFORNIA  HAS  KC  OHF/ HF  RADIOS  AVAILABLE  ALREADY 

(If  the  number  of  available  radios  is  already  zero 
(0) ,  and  you  attempt  to  delete  a  radio.) 


Figure  3.105  Naming  —  Radio  Numbers  Hismatch. 


Once  the  transaction  (adding  or  deleting  a  radio)  has  been 
completed,  you  will  be  returned  to  the  module  master  menu 
(Figure  3. 102)  . 

2 .  Display  of  a  Commun ications  Net 

If,  in  response  to  the  query  shown  in  Figure  3.102, 
you  desired  to  display  the  composition  of  a  communications 
net,  you  would  enter  two  (2).  As  this  display  will  be  on 
the  graphics  monitor,  you  will  be  first  asked  which  monitor 
you  desire  to  use.  The  format  for  this  query  is  shown  in 
Figure  3.108,  and  the  desired  response  is  the  number 
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corresponding  to  the  nonitcr  you  want  to  use.  You  would 
next  te  presented  with  a  listing  of  the  battle  group  ccmmu- 
nications  plan.  This  plan  contains  the  names  of  twenty 
(20)  circuits,  alcng  with  the  frequency  range  of  the 
circuit,  and  the  name  of  the  Met  Control  Station  (NECOS)  . 
The  fcraat  for  this  ienu  is  shown  in  Figure  3.106. 


*  BATTLE  GECUP  COMMUNICATIONS  CIRCUITS  * 


KT  ID 

NET  NAME 

FREQ 

NECOS 

1 

TF/TG  COMMAND 

HF 

OTC 

2 

TF/TG  ORESTES 

HF 

OTC 

3 

TF/TG  ORESTES 

UHF 

OTC 

4 

AAW  CMD  &  RPT  PRIMARY 

HF 

AAWC 

5 

AAW  CMD  &  RPT  SECONDARY 

HF 

AAWC 

6 

AAW  CMD  &  RPT 

UHF 

AAWC 

7 

EW  REPORTING 

HF 

EWC 

8 

EW  REPORTING 

UHF 

EWC 

9 

SSSC 

HF 

ASUWC 

10 

SAC  NET  ALFA 

UHF 

ASUWC 

11 

SAC  NET  BRAVO 

UHF 

ASWC 

12 

VP  COORDINATION 

UHF 

ASWC 

13 

LINK  11 

HF 

AAWC 

14 

LINK  11 

UHF 

AAWC 

15 

LINK  14 

HF 

AAWC 

16 

LINK  14 

UHF 

AAWC 

17 

PRITAC 

UHF 

OTC 

18 

PRI  Cl 

UHF  (S) 

OTC 

19 

DATA  LINK  COORDINATION 

HF 

AAWC 

20 

DATA  LINK  COORDINATION 

UHF 

AAWC 

(SELECT  THE  AEPROEBIATE  CIRCUIT  ID  NUMBER  (CRT  ID)) 


Figure  3.106  Battle  Group  Communications  Circuits. 

The  result  cf  this  entry  will  be  a  fan  shaped 
display  cn  the  graphics  monitor.  Within  this  fan,  will  be 
the  net  control  station,  and  the  unit  on  which  it  is 
embarked,  at  the  hub.  There  will  then  be  lines  projecting 
cutwaids,  at  the  end  cf  which  will  be  the  names  of  the  units 
who  are  participants  cn  that  net.  Finally  the  name  of  the 
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circuit  being  displayed  will  be  shown  across  the  bottom  of 
the  ecsitor  screen. 

The  display  will  be  cclor  keyed  to  highlight  several 
considerations  about  the  circuit.  As  was  mentioned 

earlier,  the  mission  area  assigned  to  a  unit  determines  its 
participation  on  a  force  radio  circuit.  Those  units  whose 
primary  mission  requires  them  to  be  on  the  net  will  be 
connected  tc  the  hub  with  w green"  lines.  Those  units  whose 
secondary  missions  require  them  to  be  on  the  net  are 
connected  tc  the  hub  with  "cyan*'  lines.  The  overall  color 
of  the  hub  and  the  circuit  name  indicate  the  frequency  of 
the  circtit.  If  the  color  is  "yellow,"  the  circuit  is  a 
OHF  net.  If  the  cclor  is  "red,"  the  circuit  is  an  HF  net. 
The  final  information  which  is  color  keyed,  applies  tc  OHF 
nets.  It  is  conceivable  that  a  unit  may  be  required  on  a 
particular  OHF  net,  however,  due  to  range  from  the  NECCS, 
participation  HAT  be  impaired.  To  accent  this  possibility, 
on  OBI  nets,  a  participating  unit  whose  range  is  greater 
than  35  nautical  miles  from  the  NECOS  will  have  its  name 
shown  in  "red. "  The  normal  color  for  the  ships'  names  is 
"yellow,"  indicating  that  the  unit  is  within  communications 
range  of  the  NECOS.  This  "legend"  information  will  be 
displayed  on  the  terminal  screen  each  time  you  display  a 
circuit.  The  format  for  this  legend  is  shown  in  Figure 
3.107.  When  you  have  completed  with  the  circuit  graphics 
display, 

KB  —  <cr> 

VB  —  "Carriage  Return" 

you  would  make  the  following  entry,  and  will  be  cycled  back 
to  the  mcdule  menu  (Figure  3.102). 


*  GRAPHICS  LEGEND  * 


DISPLAY 

COLOR 

DESRCRIPTION 

SHIP  NAMES 

RED 

YELLOW 

OUT  OF  COMM  RNG  OF 
WITHIN  COMM  RNG  OF 

NECOS 

NECOS 

CONNECTING 

LINES 

GREEN 

CYAN 

PRIMARY  MISSION  REC 
SECONDARY  MISSION  I 

}MT 

cEQMT 

NECOS  LAEEL/ 

CIRCUIT  NAME 

T  ELLON 
RED 

UHF  CIRCUIT 

HF  CIRCUIT 

***  PRESS  RETORN  TO  CONTINUE  *** 


Figure  3. 107  Communications  Display  Legend. 

J.  SI1SCR  HODOLE  OPERATIONS 

The  SENSOR  module  utilizes  computer  graphics  in  allowing 
you  to  display  the  ccverage  areas  of  the  various  sensors  of 
each  unit  in  the  battle  group.  As  this  module  does  use 

graphics,  if  you  do  net  have  a  graphics  capability  where  you 
are  working,  you  will  be  unable  to  operate  within  this 
module.  In  addition  to  the  sensor  coverage  displays,  you 
can  display  the  cartesian  coordinate  axes,  the  threat 
sector,  as  well  as  experiment  with  changing  the  position  of 
a  unit  and  observing  the  effects  on  coverage  area  effective¬ 
ness.  You  invoke  the  SENSOR  module  by  making  the  following 
response  to  the  query  shown  in  Figure  3.6. 

KB  —  SENSOR  <cr> 

▼R  —  "Sensor  Module" 


Unigue  to  the  operations  of  the  computer  system  in  the 
WABLAE  at  NPS,  you  would  next  be  queried  as  to  your  desires 


regarding  the  graphics  terminal  to  be  used.  This  query  is 
in  reference  to  the  terainal  nuaber.  The  coapcsition  of 
this  query  is  shown  in  Figure  3.108. 


???  SBICH  B  A  MT  E  K  HCNITOB  DC  YOU  DESIBE  TO  UTILIZE  ??? 

1  —  FBCNT  BAY 

2  —  REAB  BAY 

3  —  CENTEB  BAY 


Figure  3.108  Selection  of  Graphics  Monitor  for  Display. 


The  desired  response  to  this  query  is  the  number  corre¬ 
sponding  to  the  aonitcr  you  intend  to  use.  Should  there  be 
an  error  ir.  making  this  response,  the  stateaent  shown  in 
Figure  3.109  will  be  presented. 


PLEASE  MAKE  YOOB  SELECTION  (1,  2,  OR  3)  FROM  THE  MEND. 
***  PRESS  BETOBN  10  CONTINUE  **♦ 


Figure  3.109  EBBOB  —  Graphics  Monitor  Selection. 


Nhen  you  enter  " RETU ES"  (as  shown  in  Figure  3.111),  you  will 
again  be  presented  with  the  query  shown  in  Figure  3.108,  and 
can  reenter  your  response. 

The  first  tiae  you  invoke  this  module  in  a  system 
sessicn,  the  information  shown  in  Figure  3.110,  a  summary  of 
the  capabilities  of  the  module,  will  be  presented. 


BATTLE  GROUP  ASSET  MANAGEMENT 
DECISION  SUPPORT  SYSTEM 

*  SENSOR  NODDLE  * 

THIS  IS  THE  SENSOR  MODULE  FOR  THE  BATTLE  GROUP  ASSET 
MANAGEMENT  DECISION  SUPPORT  SYSTEM.  IN  THIS  MODULE, 

YCU  CAN  GRAPHICALLY  DISPLAY  YOUR  BATTLE  GROUP’S  AIR, 
SURFACE,  SUBSURFACE,  AND  FIBE  CONTROL  SENSOR  COVERAGE 
AREAS,  AS  NELL  AS  POSITIONS,  AND  EXPERIMENT  WITH  THOSE 
COVERAGE  AREAS  BY  MOVING  A  UNIT  AND  OBSERVING  THE 
EFFECT  CN  COVERAGE.  THE  NECESSARY  COMMANDS  ARE  SIM- 
ILAR  TO  THOSE  YOU  UTILIZED  IN  THE  STATUS  MODULE,  AS 
S BONN  IN  THE  NEXT  FRAME. 

**♦  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.110  SENSOR  Module  Description. 

Nhile  you  have  seen  the  procedure  to  enter  "RETURN"  before. 
Figure  3.111  shows  the  format  for  the  entry  of  the  RETURN 
command  as  required  here. 


KB  — 

<cr> 

VR  — 

"Carriage  Return" 

■ 

Figure  3.111  Entry  of  "CAHRIAGE  RETURN"  or  "RETURN". 


ihen  you  continue,  you  will  be  presented  with  the  module 
command  options,  which  are  shown  in  Figure  3.112.  The 
entry  c£  these  commands  is  similar  to  the  format  and  struc¬ 
ture  of  those  commands  which  you  utilized  in  the  STATUS 
Module. 

The  desired  response  to  this  query  is  the  one  or  two  segment 
entry  shewn  in  the  mcdule  command  options.  As  you  saw  in 
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*  SENSOR  MODULE  COMMANDS  * 


DISPLAY  POSITIONS 


DISPLAYS  POSITIONS  OF  ALL 
FORCE  UNITS 

DISPLAYS  FORCE  SURFACE 
RADAR  COVERAGE 
DISPLAYS  FORCE  AIR  RADAR 
COV  ERAGE 

DISPLAYS  FORCE  SONAR 
COV  ERAGE 

DISPLAYS  FORCE  FC  RADAR 
COV  ERAGE 

(AFTER  COMPLETION  OF  ANY  OF  THE  ABOVE  COMMANDS 
YOU  SILL  BE  ASKED  IF  YOU  DESIRE  TO  MOVE  A  UNIT 
OR  DISPLAY  A  THREAT  AXIS.) 

RETURN  TO  THE  MAIN  MODULE 


SURFACE 

AIR 

SONAR 

FCRADAR 


EXIT 


PLEASE  ENTER  YOUR  SENSOR  MODULE  COMMAND 


Figure  3.112  SEISOR  Module  —  Command  Foraats. 

the  STATUS  irodule,  the  system  will  look  at  the  command  you 
enter,  and  break  the  command  into  segments.  The  key  tc  the 
evaluation  cf  the  command  in  this  module  is  the  first  word, 
DISPLAI  cr  EXIT.  Se  will  discuss  each  of  these  options, 

and  their  respective  second  segments  in  the  following 
sections.  If  there  is  a  mistake  made  in  entering  your 
command,  the  statement  shown  in  Figure  3.113  will  be 
presented. 


PLEASE  REENTER  YOUR  COMMAND  EXACTLY  AS  SHOWN  IN  THE 
SELECTIONS  LIST. 


Figure  3.113  EBBOR  —  SENSOR  Module  Command  Entry. 
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1.  SENSOR  Module  zz  Returning  to  the  MAIM  Module 


If  you  desired  to  return  to  the  MAIN  module,  you 
would  sake  the  following  entry  in  response  to  the  query 
shown  in  Figure  3.112. 

KB  —  EXIT  <cr> 

VR  —  ’'Return  to  Main  Module" 


2.  SENSOR  Module  —  Display  of  Force  Pos itions 

If  you  desired  to  display  the  positions  of  the  units 
in  the  battle  group,  you  would  make  the  following  entry  in 
response  to  the  guery  shown  in  Figure  3.112. 

KB  —  DISPLAY  POSITIONS  <cr> 

YH  —  "Display"  "Positions" 

As  a  result  of  this  entry,  you  would  have  displayed  on  the 
graphics  monitor,  the  relative  positions  of  all  force  units, 
as  indicated  by  the  locations  of  their  names. 
Additionally,  on  the  terminal  screen,  you  would  see  a  pres¬ 
entation  of  the  positions  of  the  battle  group  units,  as 
shown  in  either  Figure  3.8  9  or  Figure  3.90  (determined  by 
which  coordinate  system,  polar  or  cartesian,  is  being 
utilized).  This  display  will  be  followed  by 

***  PRESS  RETURN  TO  CONTINUE  *** 

To  continue,  you  would  make  the  entry  shown  in  Figure  3.111. 
when  you  continue,  you  will  have  the  opportunity  to  utilize 
the  ether  features  of  this  module,  enlarging  the  display, 
and  displaying  the  threat  sector  and/or  cartesian  coordinate 
axes.  The  operations  of  these  features  will  be  discussed 
in  later  topics  of  this  section.  You  will  not,  however, 
have  the  opportunity  to  move  any  units,  as  you  would  in  the 
ether  displays  of  this  module. 


3.  SENSOR  Hodule  —  pisplay  of  Force  Surface  Radar 

Saigaags 

This  feature  of  the  SENSOR  nodule  allows  you  to 
display  the  coverage  areas  of  the  surface  search  radars  on 
each  unit  in  the  force.  In  response  to  the  query  shown  in 
Figure  3.112,  you  would  make  the  following  entry  to  initiate 
this  display. 


KB  — 


DISPLAY  SURFACE 


<cr> 


VH  —  "Display"  "Surface  Search  Radars" 

This  command  initiates  a  display  of  the  relative  positions 
of  each  unit  in  the  force,  with  units  identified  by  name. 
Additionally,  around  each  unit  will  be  a  circle  scaled  to 
the  surface  search  radar  installed  onboard  that  unit.  The 
radars  and  their  respective  ranges  are  shown  in  Table  VII. 
This  display  will  be  presented  on  the  graphics  monitor.  On 
the  terminal  screen  you  will  see  the  names  of  the  units  in 
the  battle  group,  with  the  respective  onboard  radar.  The 
format  of  the  terminal  screen  display  is  shown  in  Figure 
3. 1 1  a . 


*  BATTLE  GROUP  SURFACE  SEARCH  RADARS  * 


UNIT  NAHE 


RADAR 


RANGE 


***  PRESS  RETURN  TO  CONTINUE  *** 


T1BLE  VII 

DSS  Surface  search 

Radars 

Badar 

Range  (nm) 

AN/BPS-15 

20.0 

AN/BPS-  14 

20.0 

AN/SPS-10 

30.0 

AN/SPS-55 

35.0 

AN/SPY-1 

35.0 

You  wculd  continue,  from  the  display  shown  in  Figure  3.114, 
by  making  the  entry  described  in  Figure  3.111.  when  you 
continue,  you  would  he  offered  the  options  of  enlarging  the 
plot,  displaying  the  threat  sector,  and  displaying  the 
cartesian  coordinate  axes.  These  features  are  discussed  in 
succeeding  topics  of  this  section.  In  addition,  once  the 
plot  contains  the  infcrmaticn  you  desire,  you  can  experiment 
with  coverage  areas  by  moving  up  to  ten  (10)  units.  The 
process  involved  with  moving  the  units  is  discussed  at  the 
end  cf  this  section. 

4.  SENSOR  Module  —  Pi  splay  of  Force  Air  Search  R  a  da  rs 

This  feature  of  the  SENSOR  module  allows  you  to 
display  the  coverage  area  of  each  of  the  air  search  radars 
cn  the  battle  group  units.  You  would  invoke  this  feature 
by  making  the  following  entry  in  response  to  the  query  shown 
in  Figure  3.112. 

KB  —  DISPLAY  AIR  <cr> 

VR  —  "Eisplay"  "Air  Search  Radars" 

This  command  would  result  in  the  display  of  all  units  in  the 
battle  group,  in  their  relative  positions,  and  identified  by 
name.  Around  each  unit  would  be  a  circle  scaled  to  the 
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appropriate  air  search  radar  onboard  that  unit.  The  range 
characteristics  of  the  air  search  radars  in  the  database  are 
shown  in  Table  Till  .  Additionally,  on  the  terminal 
screen,  the  composition  of  the  air  search  radars  within  the 
tattle  group  would  te  displayed.  The  format  of  this 
display  is  shown  in  Figure  3.115. 


•  l 

i 

*  BATTLE  GROOP  AIR  SEARCH  RADARS  * 

UNIT  NAME  PRIMARY  SECONDARY  RANGE 

***  PRESS  RETORN  TO  CONTINOE  *** 

, 

—  — — — - - -  . . . . . - — .... 

•  4 

Figure  3.115  DISPLAY  —  Air  Search  Radars. 


TABLE  Fill 

DSS 

Air  Search  Radars 

Radar 

Range  (ns) 

AN/SPS-48C 

220.0 

AN/S  PS  -49 

250.  0 

AN/SPS-58 

250.0 

AN/S  PS  -43  A 

270.0 

AN/SPS-37  A 

260.0 

AN/S  PS -5  2 

230.  0 

AN/SPS-40 

240.0 

AN/SPS-39 

290.0 

AN/SPY -1 

300.0 

■  — _ _ i 

You  would  continue,  following  the  display  in  Figure 
3.115,  by  making  the  entry  shown  in  Figure  3.111. 
Following  the  display  of  the  air  search  radar  coverages,  you 


would  have  the  opportunity  to  utilize  the  other  module 
features  of  changing  the  size  of  the  screen  display 
(Enlarge) ,  and  displaying  the  threat  sector  and/or  cartesian 
coordinate  axes.  These  topics  are  covered  in  succeeding 
sections.  Once  the  plot  is  as  you  desire,  you  will  te  able 
to  experiment  with  air  radar  coverages  by  moving  a  unit  and 
observing  the  resultant  change  in  coverage.  This  feature 
is  discussed  at  the  end  of  this  section. 

5.  SB M SOB  Module  —  Pi  splay  of  Force  Fire  Control  Badar 

This  capability  of  the  SENSOR  module  allows  you  to 
display  the  coverage  areas  of  the  fire  control  radars 
installed  onboard  the  units  of  the  battle  group.  The 
display  would  show  the  units  in  the  force,  in  their  relative 
positions,  and  identified  by  name.  Around  each  unit  would 
be  a  circle  of  radius  scaled  to  the  respective  fire  control 
radar  installed  on  that  unit.  Table  IX  shows  the  ranges 
for  the  fire  control  radars  in  the  systam. 

You  can  invoke  this  capability  from  the  query  shown  in 
Figure  3.112  by  making  the  following  entry, 

KB  —  DISPLAY  FCRADAR  <cr> 

YB  —  "Display"  "Fire  Control  Radars" 

In  addition  to  the  ccverage  display  on  the  graphics  monitor, 
a  chart  of  the  units  and  their  respective  fire  control 
radars  wculd  be  displayed  on  the  terminal  screen.  The 
format  fcr  this  display  is  shown  in  Figure  3.116. 

As  ycu  can  see  from  the  information  displayed  in  Figure 
3.116,  the  name  of  the  unit  as  well  as  the  types  of  primary 
and  secondary  fire  ccntrol  systems,  as  applicable,  with  the 
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TABLE  IZ 

DSS  Fire  Control 

Radars 

» 

4 

Radar 

Range  (nm) 

BK-91 

12.0 

AN/SPG-55A 

120.0 

AN/SPG  -49 

100.0 

: 

100.0 

80.0 

t 

4 

AN/SPG-S1 

80.0 

BK-7 

40.  0 

BK-76 

40.0 

BK-74 

40.  0 

BK-56 

40.0 

BK-99 

40.0 

_  . 

■  -« 

BK-68 

40.0 

I 

4 

BK-92 

40.0 

AN/SPG-S3 

60.0 

AN /SPG -60 

50.0 

MK-13 

40.0 

AN/SPQ-9 

20.  0 

AN/SPG-35 

35.0 

. 

1 

4 

*  BATTLE  GEO OP  FIRE  CONTROL  RADARS  * 

ONIT  NAHE  PRIMARY  SECONDARY  RANGE 

***  PRESS  RETORN  TO  CONTINUE  *** 


Figure  3.  116  DISPLAY  —  Fire  Control  Radars. 

range  of  the  longest  range  system  are  shown.  After  the 

graphics  and  terminal  displays  are  complete,  you  can 
continue  by  making  the  entry  shown  in  Figure  3.111.  when 
you  continue,  you  will  have  the  opportunity  to  utilize  the 
ether  features  of  this  module,  enlarging  the  size  of  the 
graphics  plct,  and  displaying  the  threat  sector  and/or  the 
cartesian  coordinate  axes.  These  capabilities  are 
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discussed  in  succeeding  sections.  Once  the  substance  of 
the  plot  is  as  you  desire,  you  will  be  able  to  experiment 
with  the  coverage  areas  by  changing  the  position  of  a  unit 
and  cbsexving  the  effect  on  coverage.  This  feature  is 
discussed  at  the  end  of  this  section. 

6.  SENSOR  Module  —  Display  of  Force  Sonar  Coverage 

This  feature  of  the  SENSOR  module  allows  you  to 
display  the  coverage  areas  of  each  of  the  ship  mounted 
sonars  in  the  battle  group.  This  capability  will  show  the 
direct  path  range  for  all  force  sonar  systems. 
Addit ionally,  when  ycu  indicate  the  conditions  exist,  the 
display  will  include  the  convergence  zone  coverages  for 
those  equipments  which  are  capable  of  a  CZ  operating  mode. 
You  invcke  the  sonar  coverage  display  by  making  the 
following  response  tc  the  query  shown  in  Figure  3.112. 

KB  —  DISPLAY  SONAR  <cr> 

V R  —  "Display”  "Sonar  Systems" 

Once  you  designate  that  you  desire  to  see  the  sonar  cover¬ 
ages,  you  will  next  te  queried  on  the  existance  of  conver¬ 
gence  zone  conditions.  This  query  is  shown  in  Figure3.l17, 
and  the  desired  response  is  a  YES/NO  answer. 


???  DO  CONVERGENCE  ZONE  CONDITIONS  EXIST  ??? 
CR  NO) 


Should  ycu  sake  an  error  in  entering  the  YES/NO  response, 
you  wculd  see  the  following  on  the  screen,  after  which  you 
can  reenter  your  YES/NO  response. 

FLEAS!  ENTE  6  "YES"  OB  "NO. " 

Remember,  £0  NOT  enter  the  quotes.  If  you  indicate  that 
convergence  zone  conditions  exist,  those  sonars  which  are  CZ 
capable  will  be  flagged  to  show  a  30  nautical  mile  annulus 
cn  the  graphics  monitor.  The  overall  display  will  show  the 
units  in  the  battle  group  in  their  relative  positions,  and 
identified  by  naae.  Surrounding  each  unit  will  be  first,  a 
"cyan"  circle  representing  the  CZ  annulus  (if  the  unit  has  a 
CZ  capable  sonar,  AND  you  indicate  the  conditions  exist), 
and  a  "green"  circle  scaled  to  the  direct  path  range  of  the 
sonar  onboard  that  unit.  Table  x  shows  the  DSS  sonars  with 
their  direct  path  ranges  and  their  CZ  capability. 


TABLE  X 

DSS  Sonar  Systems 

Sonar 

DP  Range  (nm) 

cz  Capable 

AN/EQQ-5 

Passive 

No 

AN/ EOS-  1  5 

3.0 

No 

AN/EQQ-2 

6.0 

Yes 

AN/ EOS- 6 

3.9 

NO 

AN/EOH-7 

Passive 

NO 

AN/EQS-12 

3.0 

Yes 

AN/SQS-2  3 

2.0 

NO 

AN/SQS- 26 

4.0 

Yes 

AN/SqQ-2  3 

Passive 

NO 

AN/SQS- 5 3 

4.0 

Yes 

AN/SQS-56 

3.0 

Yes 

In  addition  to  the  display  of  the  coverage  areas  on  the 
graphics  monitor,  a  summary  of  the  sonars  in  the  battle 
group,  with  respect  to  unit  capabilities,  is  presented  on 
the  terminal  screen.  The  format  for  this  display  is  shewn 
in  Figure  3.118. 


*  BATTLE  GROUP  SONAR  SYSTEMS  * 

UNIT  NAME  SONAR  RANGE 

*  **  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.118  DISPLAY  --  Battle  Group  Sonar  Systems. 

You  would  continue  by  entering  "RETURN"  as  shown  in 
Figure  3,111.  when  you  continue,  you  will  have  the  oppor¬ 
tunity  to  utilize  the  other  features  of  this  module, 
enlarging  the  size  of  the  plot,  displaying  the  threat  sector 
and/or  cartesian  coordinate  axes.  The  functions  of  these 
features  are  discussed  in  succeeding  sections.  Once  the 
plot  is  as  you  desire,  you  will  have  the  opportunity  tc 
experiment  with  the  sonar  coverages  by  changing  the  posi¬ 
tion  (s)  of  up  to  ten  units  and  observing  the  effects  on 
coverage.  These  procedures  are  discussed  at  the  end  of 
this  section. 

1 .  inc ernoration  of  ABN  Radar  Coverages 

Once  the  organic  sensor  assets  of  the  battle  group 
have  been  displayed,  regardless  of  the  capability  (air, 
surface,  etc.)  ,  you  will  be  offered  the  opportunity  to 
display  the  coverage  area  of  either  an  E-3A  or  E-2C  AEW 
aircraft.  Within  this  feature,  you  will  also  have  the 
ability  tc  input  a  specific  coverage  range  for  the 


respective  radar  onboard  the  selected  aircraft,  or  utilize 
the  system  default  range.  The  format  for  the  query  to 
invoke  this  feature  is  shown  in  Figure  3.119. 


TOO  HAVE  THE  OPTION  OF  PLACING  AN  "AW ACS"  OR  A 
"HAWKETE"  ON  STATION. 


???  WOOLD  TOO  LIKE  TO  DO  THIS  ??? 


(TES  CR  NO) 


Figure  3. 119  Query  —  Otilization  of  an  A EH  Aircraft. 


If  you  indicate  that  you  desire  to  place  the  aircraft  on 
station,  and  enter  "TES,"  you  will  next  be  asked  which  type 
cf  aircraft  you  desire  to  utilize.  The  format  for  this 
query  is  shewn  in  Figure  3.120. 


???  WHICH  AIRCRAFT  WOULD  TOO  LIKE  TO  POSITION  ??? 

1  —  E-3A  SENTRT  (AWACS) 

2  --  E-2C  HAWKETE 


(ENTER  1  or  2) 


Figure  3.120  Query  —  Determination  of  Type  of  ABW  Aircraft 


The  format  of  the  desired  response  is  straightfoward. 
Should  an  error  occur  in  making  this  response,  you  will  be 
asked  tc  reenter  your  selection.  The  next  queries  you  will 
be  presented  with  address  the  range  of  the  radar  onboard  the 


aircraft  you  select.  The  respective  query  sequences  are 
covered  in  the  next  two  sections. 

a.  Determination  of  E-3A  Radar  Range 

If  you  selected  the  E-3A  aircraft  in  response  to 
the  query  shown  in  Figure  3.120,  you  will  be  asked  if  you 
desire  tc  utilize  the  system  default  range  for  the  AN/APY-1 , 
cr  input  ycur  own  range.  The  format  of  this  query  is  shewn 
in  Figure  3.121. 


THE  AN/APY-1  RADAR  ONBOARD  THE  E-3A  AIRCRAFT  HAS  BEEN 
GIVEN  A  SYSTEM  RANGE  OF  350  NM.  YOO  HAVE  THE  OPTION 
OF  ENTERING  YCOR  CNN  RANGE  IF  YOO  DESIRE.  IF  YOO 
DESIRE  TO  OSE  THE  SYSTEM  RANGE,  PRESS  "CARRIAGE  RE- 
TORN, w  OTHERWISE,  ENTER  THE  RANGE  YOO  DESIRE. 

(LIMITS  1  -  500  NM). 


Figure  3.121  Deteraination  of  AN/APY-1  Range. 


If  ycu  desire  to  use  the  system  range,  simply  enter 
"RETORN, "  as  shown  in  Figure  3.111.  If  you  desire  to  use 
your  cwn  range,  for  example,  200  on,  you  would  make  the 
folic wing  entry. 

KE  —  200  <cr> 
vr  —  "Two"  "Zero"  "Zero"  "Carriage  Return" 

b.  Determination  of  E-2C  Radar  Range 

If  you  selected  the  E-2C  aircraft  in  response  to 
the  guery  shown  in  Figure  3.120,  you  will  be  ask«d  if  you 
desire  tc  use  the  system  default  range  for  the  AN/APS-125. 
The  format  of  the  query  is  shewn  in  Figure  3.122. 
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THE  A 8/A PS-12 5  BABAB  ONBOARD  THE  E-2C  AIBCHAFT  HAS 
EE £8  GlllS  A  SYSTEM  RANGE  OF  250  NH.  YOO  HAVE  THE 
OPTION  OF  ENTEBING  YOB  OWN  BANGE  IF  YOOB  DESIBE.  IF 
YOO  DESIBE  TO  OSE  THE  SYSTEM  BANGE,  PBESS  "CARRIAGE 
RETURN,"  OTHERWISE,  ENTBB  BANGE  YOO  DESIBE. 

(LIMITS  1  -  500  NH). 


Figure  3.122  Ceteruination  of  AN/APS-125  Bange. 


The  fcraat  for  the  desired  response  to  this  query  is  iden¬ 
tical  to  that  of  entering  the  AN/APY-1  range. 

c.  Deteraination  of  A  EH  Station 

Once  the  AEH  aircraft  has  been  identified,  you 
will  next  be  asked  to  enter  the  position  of  its  station. 
The  foraat  for  this  entry  is  different  from  the  bearing/ 
range  input  you  Bade  for  the  ships.  For  this  input,  the 
tearing/range  entry  sill  be  made  as  one  response,  and  the 
range  mill  te  entered  in  nautical  miles.  The  formats  for 
the  position  query  and  the  desired  response  are  shown  in 
Figures  3.123  and  3.124,  respectively. 


???  NEAT  IS  THE  BEAHING  AND  BANGE  OF  THE  AEW  STATION 
FFOH  ZZ  ??? 

(ENTEB  AS  "BBB  BBS"  WITH  BEABING  IN  DEGREES  TRUE,  AND 
RANGE  IN  NAUTICAL  GILES.  E.G.  BEARING  330  RANGE 

200  NH  NOULD  BE  ENTERED  AS:  330  200) 


Figure  3.123  Deteraination  of  position  of  AEW  station. 
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If  you  desired  to  place  the  AEW  aircraft  at  a  station 
bearing  225  degrees  true,  150  nautical  miles  from  ZZ, 
yen  would  make  the  folio mrg  entry.  (The  voice  format 
is  so eew hat  cumbersome!) 

KB  —  225  150  <cr> 

yjj  --  "Two"  "Two"  "Five"  "Space”  "One"  "Five" 
"Zero"  "Carriage  Return" 


Figure  3. 124  Voice/Keyboard  Response  for  AEW  Station. 

Once  the  position  of  the  AEW  station  has  been  entered,  the 
applicable  coverage  cf  the  onboard  radar  will  be  displayed, 
and  you  will  be  cycled  to  the  option  to  enlarge  the  view, 
the  next  topic. 

8.  Enlarging  tfre  Size  cf  the  Graphics  Display 

Cnee  the  display  of  the  desired  SENSOR  module 
feature  has  been  completed,  you  will  be  queried  as  to 
whether  you  desire  to  ENLARGE  the  size  of  the  plot.  When 
the  graphics  plot  is  initially  established,  the  dimensions 
cf  the  screen  are  1000  nm  by  950  nm.  In  some  cases,  this 
scale  is  toe  large  to  accurately  view  the  information  repre¬ 
sented.  This  is  particularly  true  when  displaying  posi¬ 
tions,  cr  short  range  radar  or  sonar  capabilities.  To 
allow  you  the  opportunity  to  vary  the  scale  of  the  plot  to 
meet  ycur  needs,  you  will  have  the  option  of  ENLARGING  the 
display.  The  query  addressing  this  feature  is  shown  in 
Figure  3.125. 


The  desired  response  to  this  query  is  YES  or  NO.  The 

formats  for  these  response  options  are  presented  again,  as  a 
refresher.  Should  an  error  occur  in  making  the  YES/NO 
response,  the  following  will  appear,  after  which  you  can 
reenter  the  response. 
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???  WOULD  YOU  II KE  TO  ENLARGE  THIS  VIES  ??? 
(YES  CH  NO) 


figure  3.125  Query  —  Enlarge  the  Yiev. 

PLEASE  ENTER  "YES"  OR  "NO" 

Bea enter  net  to  enter  the  quotes!  Here  are  the  correct 
response  fornats. 

KE  —  YES  <cr>  or  NO  <cr> 

VR  —  " Af f irmativ9"  or  "Negative" 

If  you  indicate  you  do  not  desire  to  enlarge  the  plot,  you 
will  continue  to  the  next  module  feature.  If  you  do, 

however,  desire  to  enlarge  the  plot,  the  guery  shown  in 
Figure  3.126,  addressing  the  number  magnifications  you  want 
applied  to  the  plot,  will  be  presented. 


???  EY  HON  MANY  TIMES  WOULD  YOU  LIKE  TO  ENLARGE  THE 
EICTUBE  ??? 

(ENTER  THE  DESIRED  NUMBER  (RANGE  2-5)) 


Figure  3. 126  Query  —  Amount  of  Enlargement. 


This  query  will  appear  only  once,  meaning  you  can  only 
change  the  scale  one  time  with  each  sensor  capability 
display.  If  the  new  scale  is  not  the  plot  size  you  desire. 
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you  would  have  to  return  to  the  module  menu  (continue 
through  the  end  of  the  sequence),  and  reinitiate  the  display 
cf  the  capability.  The  desired  response  to  the  query  shown 
in  Pigure  3.126  is  the  number  corresponding  to  the  relative 
increase  in  the  plot  size  you  prefer.  If,  for  example,  you 
desired  to  enlarge  the  plot  four  (4)  times,  you  would  make 
the  following  entry. 

KB  —  4  <cr> 

TR  —  "Four"  11  Carriage  Return” 

This  would  cause  the  plot  to  be  redisplayed  at  a  scale  four 
times  the  initial  view  size.  The  plot  would  now  have  the 
dimensions  of  250  na  by  2  37  nm.  The  coverage  currently 
being  displayed,  as  well  as  any  follow  on  feature,  will 
maintain  this  new  scale. 

The  system  will  check  your  response  to  the  query  in 
Figure  3.126  against  the  allowable  range  for  the  entry 
(2-5).  If  your  response  is  not  within  this  range,  the 
statement  shown  in  Figure  3.127  will  be  shown. 


J 

PHASE  RESTRICT  YOUR  ENTRY  TO  THE  RANGE  2-5.  j 

I 


Figure  3.127  EBROR  —  Enlargement  Scale  Not  within  Limits. 


Should  an  error  occur,  after  the  warning,  simply  reenter 
your  response  for  the  amount  of  enlargement  (2-5  times)  . 
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9  •  Displaying  the  Threat  Sector  and  Cartesian 
Coordinate  A  is  s 

Cnee  the  size  of  the  display  is  set,  and  yon  are 
satisfied  with  the  scale  of  the  plot,  yon  will  next  have  the 
epportenity  to  display  the  cartesian  coordinate  axes  and/or 
display  cr  modify  the  threat  sector.  The  query  shown  in 
Figure  3.126  addresses  these  capabilities. 


???  NCULE  TOO  LIKE  TO  SEE  EITHER  OF  THE  FOLLOWING  ??? 

1  —  VERTICAL  ELOT  AXES 

2  —  THREAT  SECTOR 

(ENTER  THE  APPROPRIATE  NUHBER  OR  PRESS  "CARRIAGE  RE¬ 
TURN"  TO  CONTINUE) 


Figure  3.128  Query  —  Threat  Sector/Vertical  Plot  Axes. 

You  will  cycle  to  this  or  the  query  shown  in  Figure 
3.129,  each  time  you  make  a  change  to  the  plot  by  moving  a 
unit  (discussed  later).  If  an  error  occurs  in  making  this 
response,  the  warning  shown  in  Figure  3.113  will  be 
presented,  after  which  you  can  reenter  your  response.  If, 
through  the  course  of  experimenting  with  coverages,  you  have 
already  displayed  the  VERTICAL  PLOT  AXES,  you  would  then 
only  be  asked  if  you  desire  to  display,  or  if  it  is  already 
displayed,  redefine  the  THREAT  SECTOR.  This  query  is  shown 
in  Figure  3.129. 

The  desired  response  to  the  query  shown  in  Figure  3.128  is 
the  YES/NO  entry  which  has  been  discussed  before.  If,  you 
do  net  desire  to  display  either  of  these  features,  ycu  would 
simply  enter  "RETURN"  as  shown  in  Figure  3.111,  and  you  will 
cycle  to  the  next  module  feature,  changing  the  positions  of 
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- i 

???  SCOLD  YOU  LIKE  TO  DISPLAY  OH  REDEFINE  THE  THREAT  I 

SECTOR  ???  j 

(YES  CR  NO)  I 


Figure  3. 129  Query  —  Display/Redefine  Threat  Sector. 

the  units.  This  feature  is  discussed  at  the  end  of  this 
section.  Let's  first  look  at  each  of  these  display 

features  (threat  sector/cartesian  grid)  and  their  guery 
sequences  individually. 

a.  Display  of  the  Cartesian  Coordinate  Grid 

If  you  desired  to  display  the  cartesian  coordi¬ 
nate  grid  (VERTICAL  PLOT  AXES)  ,  you  would  make  the  following 
entry  in  response  to  the  query  shown  in  Figure  3.128. 

KB  --  1  <cr> 

v R  —  "One"  "Carriage  Return" 

This  response  will  immediately  cause  the  graphics  monitor 
display  to  te  refreshed,  this  time  displaying  the  cartesian 
grid,  scaled  to  your  enlarged  plot,  if  applicable,  along 
with  the  capability  coverage  you  are  viewing.  Until  you 

erase  the  graphics  monitor  view  (return  to  the  module  menu) , 
the  grid  will  be  continuously  displayed.  Once  the  grid  has 
been  displayed,  you  will  be  given  the  query  shown  in  Figur® 
3.129,  to  provide  you  the  opportunity  to  display  the  threat 
sector.  We  will  eow  look  at  the  sequences  involved  witu 
the  display  of  the  threat  sector. 

t.  Display  of  Threat  Sector 

You  would  cause  the  threat  sector  to  be 
displayed  by  making  the  appropriate  response  to  the  queries 
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shown  in  Pigure  3.128,  or  Figure  3.129.  There  are  two 
different  query  sequences  which  follow  the  response  to 
display  the  sector.  These  sequences  are  keyed  to  whether 
the  sector  is  already  being  displayed.  If  the  sector  is 
already  displayed,  then  you  will  be  given  the  opportunity  of 
redefining  the  sector.  He  will  look  at  both  cases. 

(1)  Sgstoi  lajtjai,  DiiBlaj.  If  the 
threat  sector  has  as  yet  not  been  displayed,  the  first  query 
you  will  see  is  shown  in  Figure  3.130. 


???  HHAT  IS  THE  THBEAT  BEARING  ??? 

(ENTER  BEARING  IN  E  EG  REES  (0  -  359)) 

Figure  3.130  Query  —  Defining  Threat  Bearing. 

If  the  force  faced  a  threat  from  a  bearing  of  300  degrees 
true,  the  following  entry  would  be  made  in  response  to  the 
query  shewn  in  Figure  3.130. 

KB  —  300  <cr> 

VR  —  "Three"  "Zero"  "Zero"  "Carriage  Return" 

The  system  will  check  the  entry  to  ensure  it  is  within  the 
authorized  limits  (0  -  359),  and  should  it  not  be  within 
those  limits,  the  following  warning  will  appear,  after  which 
you  can  reenter  jour  threat  bearing. 

YOOR  ENTRY  HAS  NOT  BEEN  ACCEPTED.  PLEASE  REENTER  THE  THREAT 
HEARING  IN  DEGREES  (0  -  359). 

Once  the  threat  bearing  has  been  determined,  you  will  next 
be  asked  for  the  width  of  the  threat  sector.  This  query  is 
shown  in  Figure  3.131. 


J  / 


???  9 HAT  IS  THE  THREAT  SECTOR  WIDTH  ??? 


~1 


(ENTER  IN  DEGREES  (0  -  360)) 


figure  3.131  Query  —  Threat  Sector  Width. 


As  an  example,  if  the  threat  sector  is  90  degrees  vide,  the 
following  weald  be  the  correct  entry  in  response  to  this 


query. 


KB  — 


<cr> 


vb  --  "Nine"  "Zero"  "Carriage  Return" 

If  a  mistake  were  to  occur  when  aaking  this  response,  the 
following  warning  would  appear,  after  which  you  could 
reenter  the  threat  sector  width. 

YOOR  ENTBY  HAS  NOT  BEEN  ACCEPTED.  PLEASE  REENTER  THE  THREAT 
SECTOB  WIDTH  IN  DEGREES  (0  -  360)) 

Once  the  threat  bearing  and  sector  width 
have  been  correctly  input,  the  graphics  monitor  will  now 
redisplay  all  the  current  information,  plus  the  threat 
sector.  The  sector  will  be  narked  in  red,  centered  on  the 
threat  tearing,  and  originates  at  "ZZ."  Now  that  the 
threat  sector  has  been  displayed,  each  time  you  cycle 
through  the  query  shown  in  Figure  3.129,  you  will  have  the 
opportunity  to  redefine  the  existing  sector,  if  you  so 
desire.  This  is  the  topic  of  the  next  section. 

(2)  Bsis&nisa  IBS  sector.  If  you 

desired  to  redefine  an  already  existing  threat  sector,  you 
would  enter  "YES"  to  the  query  shown  in  Figure  3.129.  This 
response  will  result  in  the  query  shown  in  Figure  3.132, 
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presenting  the  parameters  cf  the  existing  sector  to  you. 
is  sheen,  the  query  reflects  the  sector  parameters  which 
were  used  in  the  previous  exaaple. 


TEE  TEREAT  SECTOR  IS  CURRENTLY  90  DEGREES  RIDE,  CEN¬ 
TERED  ON  i  BEARING  OF  300  DEGREES  TROE. 

???  IS  THIS  STILL  CORRECT  ??? 

(TES  CR  NO) 

Pi gore  3.132  Description  of  Existing  Threat  Sector. 

The  desired  response  is  TES  or  NO.  If  70a  indicate  that 
the  enrrent  sector  is  correct,  by  entering  YES,  you  will 
continue  to  the  nodule  feature  where  you  can  experiment  with 
unit  positions.  If  you  would  like  to  change/redefine  the 
sector,  and  enter  NC,  you  will  repeat  the  query  sequences 
starting  with  that  shewn  in  Figure  3.130,  and  discussed 
above.  Should  an  error  occur  in  making  the  YES/NO 

response,  ycu  would  be  asked  to  reenter  the  response. 

10.  Experimenting  with  Moving  a.  Unit 

A  significant  feature  of  the  computer  graphics  capa¬ 
bilities  of  this  DSS  is  allowing  the  user  to  experiment  with 
the  effect  cn  sensor  (or  weapons  systam,  discussed  later) 
coverage  cf  moving  a  unit.  To  afford  you  the  opportunity 
to  redeploy  the  forces  of  the  battle  group,  in  order  to  best 
grasp  the  optimui  overall  coverage  effectiveness,  this  DSS 
feature  allows  you  to  move  up  to  ten  (10)  units.  (The  limit 
of  10  was  determined  based  on  the  amount  of  clutter  on  the 
graphics  monitor  when  an  inordinate  number  of  ships  were 


moved,  thereby  displaying  both  their  old  and  new  positions, 
and  coverages.)  Each  of  these  ten  units  can  be  moved  an 
indefinite  nuaber  of  tises,  however.  Unfortunately,  the 
ESS  has  not  been  designed  to  allow  you  to  move  the  AEW 
aircraft,  cnce  they  are  in  place.  This  change  in  unit 
position  is  not  to  he  confused  with  the  changing  of  posi¬ 
tions  in  the  STATUS  module.  The  position  change  in  this 
nodule  is  temporary  and  will  not  be  aade  permanent,  as  you 
will  see.  The  query  utilized  to  invoke  this  feature  is 
shown  in  Figure  3.133. 


???  DO  YOU  DESIRE  TO  EXPEBIHENT  WITH  COVERAGES  BY 
MOVING  A  UNIT  ??? 

(YIS  CR  NO) 

(YOU  CAN  INDIVIDUAI1Y  MOVE  UP  TO  TEN  (10)  UNITS.) 


Figure  3.133  Query  --  Hove  a  Battle  Group  Unit. 


The  desired  response  to  this  query  is  "YES"  or  "NO,"  the 
format  for  which  you  have  seen  before.  If  you  indicate 
that  you  desire  to  neve  a  unit,  and  enter  "YES,"  the  first 
query  you  will  see  is  to  identify  the  unit  you  desire  to 
move.  The  format  of  this  query,  with  a  representative  ship 
names,  is  shown  in  Figure  3.134. 

If  an  error  occurs  when  making  this  response,  or  the  name 
entered  cannot  be  matched  to  the  names  of  the  battle  group 
units,  ycu  will  be  asked  to  reenter  the  name  of  the  unit  you 
desire  to  move.  Once  the  unit  to  be  moved  is  identified, 
you  wculd  next  be  asked  for  the  new  position  of  that  unit. 
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??  iHAT  IS  THE  BABE  OF  THE  QUIT  TOO  DESIRE  TO  MOVE  ?? 
CARL  VINSON  PA0L  I  FOSTER  CALIFORNIA 

- ....  _  -  -  -  -  - -  - - . - < 


Figure  3.134  Query  —  Naae  of  the  Unit  to  be  floved. 

The  forest  cf  this  query  is  based  on  the  type  of  coordinate 
system  (polar  or  cartesian)  in  use.  The  query/response 
sequences,  however,  are  identical  to  those  used  in  the  BOILD 
module.  If  you  are  using  the  polar  coordinate  system,  you 
will  be  asked  for  the  bearing  and  range  of  the  ship's  new 
position  free  "ZZ."  If  you  are  using  the  cartesian  system, 
you  will  be  asked  for  the  quadrant,  x  and  y  positions  of  the 
unit.  Since  these  sequences  are  ones  with  which  you  are 
already  familiar,  they  will  net  be  repeated  here.  If  you 
need  to  review  their  formats,  you  should  refer  to  the  appro¬ 
priate  section  of  the  BOILD  module.  Remember,  the  new 
position  is  of  a  temporary  nature  until  you  state  otherwise. 

Hhen  the  new  position  of  the  unit  has  been  entered, 
the  display  on  the  screen  will  be  repeated,  this  time, 
showing  the  n9w  as  well  as  the  current  system  position  for 
the  unit  ycu  moved.  This  contrasting  display  will  give  you 
a  feel  fer  the  dynamics  of  the  change  you  made.  Once  the 
new  display  has  been  presented,  you  will  be  asked  if  you 
desire  this  NEW  position  be  made  permanent.  The  format  for 
this  query  is  shown  in  Figure  3.135. 


The  desired  response  to  this  query  is  ’'YES''  or  "NO,”  the 
format  of  which  we  tave  discussed  before.  If  ycu  do  not 
want  this  position  change  to  be  made  permanent,  enter  "NO," 
and  you  will  cycle  tc  the  query  regarding  the  display  of  the 
threat  sectcr  or  cartesian  grid,  as  appropriate.  For  the 


I  ^ 
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???  DO  TOO  I MIT  THIS  CHANGE  TO  BE  HADE  PERMANENT  ??? 


I 

(IBS  CB  HO) 


Figure  3.135  Query  —  lev  Position  to  be  Hade  Permanent. 

reiaind®r  of  the  capability  display,  however,  the  new  posi¬ 
tion  cf  the  unit  will  be  displayed  along  with  the  current 
systea  position.  Ycu  can  change  the  position  of  up  to  ten 
(10)  units.  You  can  also  cone  bach  to  any  unit  and  make 
another  position  change  if  you  desire.  When  you  nc  longer 
indicate  that  you  desire  tc  change  th9  position  of  a  unit, 
you  will  complete  the  full  display  capability  of  this 
■odule,  and  you  will  be  advised  that  th6  displayed  graphics 
will  be  erased  when  you  continue.  This  warning  is  shown  in 
Figure  3.136. 


**  CAPTION  **  -  THE  DISPLAYED  GBAPHICS  W ILL  EE 

ZBASIC  WHEN  YOU  CONTINUE 

PBESS  HETUHN  TO  CONTINOE  *** 


Figure  3.136  WARNING  —  Erasure  of  Displayed  Graphics. 


You  would  continue  by  entering  ” RETURN"  as  shown  in  Figure 
3.111,  and  you  will  be  returned  to  the  nodule  menu  (Figure 
3.112)  . 


I 
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K.  WEAPONS  BO  DO  IE  OFIHATIONS 

The  functioning  cf  the  WEAPONS  nodule  is  oriented  to 
computer  graphics  displays  of  the  capabilities  of  the  battle 
group  weapons.  The  purpose  of  this  aodule  is  to  allow  you 
to  display  the  force  weapons  capabilities  in  AAW ,  ASW,  and 
ASUW.  Tou  would  invoke  the  WEAPONS  Module  from  the  query 
shown  in  figure  3.6.  The  foraat  for  this  response  is  shewn 
in  the  following  exaaple. 

KB  —  WEAPONS  <cr> 

VB  —  "Weapons  Module" 

The  initial  view  which  you  observe  upon  invoking  this  aodule 
is  shewn  in  Figure  3.137  (adjusted).  The  inforaaticn  shown 
discusses  the  capabilities  of  the  nodul9.  This  display 
will  cnly  cccur  after  the  first  invocation  of  the  aodule. 
Tou  can  continue  by  entering  "RETURN,"  as  shown  in  Figure 
3.138. 


•  BATTLE  GROUP  ASSET  MANAGEMENT  * 

DECISION  SUFFORT  SYSTEM 

*  WEAPONS  MODULE* 

THIS  MODULE  WILL  ALLOW  YOU  TO  DISPLAY  THE  FORCE  WEA¬ 
PONS  EFFECTIVENESS  AREAS.  YOU  WILL  BE  ABLE  TO  DISPLAY 
MISSUS,  GUN,  AND  ASW  WEAFCNS  SYSTEMS,  AS  WELL  AS 
TCHAHAWK  AND  HARPCCN  EFFECTIVENESS  AREAS.  AS  WITH 
THE  SSHSCR  MODULE,  YOU  WILL  EE  ABLE  TO  DISPLAY  THE 
CARTESIAN  AXES,  TEE  THREAT  SECTOR,  AND  EXPERIMENT  WITH 
EFFECTIVENESS  BY  MOVING  A  UNIT  AND  OBSERVING  THE  RE¬ 
SULTANT  EFFECT. 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.137  WEAPONS  Module  Description 


KB  —  <cr> 

VR  —  "Carriage  Return" 


Figore  3.138  Entry  of  "C1MI1SE  RETOBH"  or  "RETOHH". 


After  you  continue,  the  next  display  will  be  the  one  which 
will  serve  as  the  aajcr  aenu  for  the  nodule.  The  composi¬ 
tion  of  this  aenu,  which  also  functions  as  a  query,  is  shown 
in  Figure  3.139.  This  menu  is  a  straight foward  explanation 
of  the  categories  of  the  displays  available. 


*  WEAPONS  BODOLE  OPTIONS  * 

MISSILE  —  DISPLAY  FO  RCE  MISSILE  SYSTEMS 

GUN  —  DISPLAY  FORCE  GON  SYSTEMS 

MSLGON  —  DISPLAY  FORCE  MISSILE  AND  GON  SYSTEMS 

ASW  —  DISPLAY  FORCE  ASH  WEAPONS  SYSTEMS 

TOMAHAWK  —  DISPLAY  FORCE  TOMAHAWK  WEAPONS  SYSTEMS 
HABPCON  —  DISPLAY  FORCE  HARPOON  WEAPONS  SYSTEMS 
TCMHAR  —  DISPLAY  FORCE  TOMAHAWK  AND  HARPOON 
WEAPONS  SYSTEMS 

EXIT  —  RETORN  TO  THE  MAIN  MODULE 

???  WHAT  IS  YOOR  SELECTION  ??? 


Figure  3.139  WEAPONS  Module  Options. 


The  desired  response  to  this  query  is  the  name  of  the  option 
you  desire.  Should  a  keyboard  error  occur  in  making  this 
reponse,  the  following  warning  will  be  displayed. 

YOOR  SELECTION  WAS  NCT  ACCEETED  BY  THE  PROGRAM,  AND  YOO  WILL 


HAVE  TO  REENTER 


| 


Cnee  70a  have  aade  year  selection,  the  system  will  attempt 
to  eatch  50 or  response  to  one  of  the  options  available.  If 
no  aatch  is  aade,  then  the  warning  shown  in  Figure  3. 140 
will  be  displayed. 


TOOB  RESPONSE  IS  BCT  RECOGNIZE ABLE  AS  BEING  FROM  THE 
AVAILABLE  OPTIONS 

*♦*  PRESS  BET  URN  TO  CONTINUE  *** 


Figure  3.140  ERROR  -  No  Batch  of  Input  To  Available  Options 

Iou  can  continue  by  entering  RETURN,  as  shown  in  Figure 
3.138.  When  ycu  continue,  the  module  menu  (Figure  3.139) 
will  again  be  displayed  and  you  can  reenter  your  response. 
Identical  tc  the  capabilities  of  the  SENSOR  module,  this 
aodule  also  allows  you  several  special  features.  These 
features  include  enlarging  the  size  of  the  plot,  display  of 
the  cartesian  axes,  display  of  a  threat  sector,  and  experi- 
aentally  moving  a  unit  and  observing  the  effects  the  move 
has  on  weapons'  coverage.  Iou  will  also  have  the  capa¬ 
bility  of  imposing  a  CAP  station  on  top  of  the  ship  system 
coverages.  The  pragmatics  involved  with  responding  to  the 
queries  associated  with  these  special  features  have  already 
been  discussed  in  the  SENSOR  module  operations  section,  and 
will  not  be  discussed  here.  The  points  at  which  these 
features  may  be  invoked  in  the  WEAPONS  aodule  will,  however, 
be  eaphasized.  Additionally,  as  you  have  seen  in  the 
SENSOR  mcdule,  in  most  cases,  the  graphics  displays  will  be 
paralleled  with  a  capabilities  display  on  the  terminal 
screen.  The  results  of  selecting  aach  of  the  available 


WEAPONS  todule  options  will  be  discussed  in  the  following 
topics  of  this  section. 

1 .  Display  of  Available  Options 

In  the  succeeding  sections,  we  will  discuss  the 
sequences  involved  with  the  various  display  options  in  this 
■odule.  Following  the  explanation  of  the  individual 
options,  the  sequences  associated  with  enlarging  the  plot, 
stationing  a  CAP,  and  the  display  of  the  cartesian  axes  and 
threat  sector  are  discussed  with  respect  to  the  queries  you 
will  see  to  initiate  them.  For  a  detailed  explanation  of 
the  functioning  of  each  of  these  features,  you  should  refer 
to  the  appropriate  section  in  SENSOR  MODULE  OPERATIONS. 
The  raticnale  for  changing  the  scale  would  be  that  in  seme 
displays,  the  coverage  areas  of  the  capability  selected 
could  be  seen  in  more  detail  when  the  scale  is  changed. 
The  initial  size  of  the  graphics  plot  is  1000  by  950 
nautical  miles.  You  will  be  able  to  change  this  size  to  a 
minimum  cf  200  by  190  nautical  miles,  if  you  so  desire. 
For  a  review  of  the  eperatiens  of  this  feature,  again,  you 
should  refer  to  the  appropriate  section  within  SENSOR  M0D0LE 
OPERATIONS.  Now  we  will  look  at  the  various  WEAPONS 

module  options. 

a.  Display  cf  Force- Missile  System  Coverage  Areas 

If  you  desired  to  display  the  coverage  areas  of 
the  fcrce  missile  systems,  then  your  response  would  te  as 
shown  below. 

KB  —  MISSILE  <CT> 

VR  —  "Guided  Missile  Systems" 

The  result  cf  this  entry  would  be  a  display  on  the  graphics 
monitor  cf  the  battle  group  units  in  their  relative  posi¬ 
tions,  identified  by  name,  and  as  applicable,  surrounded  by 
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a  circle  scaled  to  tie  capability  of  their  installed  missile 
systea.  The  DSS  ranges  for  individual  missile  systems  are 
shown  in  Table  XI. 


TABLE  XI 

DSS  Bissile  Systea  Ranges 


Hissile  System 

NSSHS  (RIM-71 
SM1-ER  JRIH-67) 
BP  CHS  (  RIM -7) 
SM2-MH  (RIH-66C) 
SM1-HH  (RIM66B) 
SH2-ER  (RIM-67B) 


Range  (nm) 

7.0 

40.0 

6.5 

50.0 

25.0 

90.0 


On  the  terminal  screen  would  be  a  summary  of  the  force 
systeas,  identified  by  ship  name,  primary  system  type, 
secondary  systea  type,  and  longest  operational  range.  The 
format  fcr  the  terminal  display  is  shown  in  Figure  3.141. 


*  BATTIE  GROUP  HISSILE  SYSTEMS  * 

QUIT  SAME  PRIMARY  SYSTEM  SECONDARY  SYSTEM  RANGE 
***  PRESS  RETURN  TO  CONTINUE  ♦** 


Figure  3.141  Terminal  Display  -  Battle  Group  Hissile  Sys 


Cue 9  the  missile  system  capabilities  have  been  displayed, 
you  will  be  able  to  change  the  scale  of  the  plot,  or  display 
the  threat  sector  and  cartesian  coordinate  axes,  as  veil  as 
experiment  vith  changing  a  unit's  position.  The  queries  to 
initiate  these  features  are  shown  in  succeeding  sections. 

t.  Display  cf  Force  Gun  Weapons  System  Coverages 

If  you  desired  to  display  the  force  gun  weapons 
system  ccverage  areas,  you  would  make  the  following  response 
to  the  query  shown  in  Figure  3.139. 

KE  —  GDN  <cr> 

—  "Gun  Systems" 

Is  a  result  of  this  input,  you  would  see  a  display  on  the 
graphics  mcnitor  of  all  the  battle  group  units  in  their 
relative  positions,  and  identified  by  name.  Additionally, 
you  wculd  see  in  the  display,  a  circle  of  radius  scaled  to 
the  onboard  gun  system  capability,  surrounding  each  unit. 
Table  XII  shows  the  DSS  ranges  for  th9  available  gun  weapons 
systems. 


TABLE  XII 

DSS  Gun  System  Ranges 

Gun  System 

Range  (nm) 

16"/50  (406  mm)  MK7  MOD  0 

5"/38  ( 1  27  mm)  MK12  MOD  1 

20.0 

10.0 

2mm /70  HK4 

5"/54  (1  27  mm)  MK42 

3.0 

13.0 

5"/54  (127  mi)  MK45 

13.0 

3"/50  (76  am)  MK22 

10.0 

76  mm  (OTO  MELARA) 

8.0 

On  the  terminal  screen  would  be  displayed  the  gun  capabili¬ 
ties  by  ship  naae,  gun  systee  installed,  and  gun  range. 
The  fcraat  for  this  presentation  is  shown  in  Figure  3.142. 


*  BATHS  GROUP  GUN  SYSTEBS  * 

UNIT  BABE  STSTEB  RANGE 

***  PRESS  RETUBN  TO  CONTINUE  *** 


Figure  3.142  Battle  Group  6un  Systeas. 


Once  the  gun  ranges  are  dislayed,  you  will  be  able  to  change 
the  scale  cf  the  plot,  and  display  the  threat  sector  and 
cartesian  coordinate  axes,  as  well  as  experiaent  with 
changing  a  unit's  position.  The  queries  to  initiate  these 

features  are  shown  below. 

c.  Display  cf  Force  Bissile  and  Gun  Heapons  Systeas 

If  you  desire  to  display  the  force  coverage 
areas  with  respect  to  BOTH  missile  and  gun  systeas 
installed,  then  you  would  enter  the  following  in  rsponse  to 
the  guery  shown  in  Figure  3.139. 

KE  —  BSLGUN  <cr> 

VR  —  "Ecth  Missile  and  Gun  Systems" 

This  input  would  initiate  a  display  on  the  graphics  acnitor 
showing  the  coverage  areas  for  both  the  missile  (shown  in 
"green")  ,  and  the  gun  systems  (shown  in  "red")  for  the 
battle  group.  Refer  to  Table  XI  and  Table  XII  for  a 
summary  cf  the  ranges  associated  with  the  various  missile 
and  gun  systems  available.  Additionally,  the  type  of 
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installed  systems  would  be  shown  ,  by  ship  naae,  on  the 
terainal  screen.  The  foraat  of  this  display  is  shown  in 
Figure  3.143. 

a 


*  BATTLE  GROUP  MISSILE  AND  GUN  SYSTEMS  * 

GRIT  NAME  MISSILE  SYSTEM  GUN  SYSTEM 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3. 143  Force  Missile  and  Gun  Systeus. 
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Following  these  displays,  you  will  be  able  to  enlarge  the 
plot,  and  display  the  threat  sector  and  cartesian  coordinate 
axes,  as  well  as  experiaent  with  changing  a  unit's  position. 
The  gueries  and  associated  responses,  reguired  to  initiate 
these  features,  are  shown  in  succeeding  sections  of  this 
aodule. 


d.  Display  cf  Force  AS1  Weapons  Systea  Coverages 

If  you  desire  to  display  the  force  ASH  weapons 
systeas,  ycu  would  enter  the  following,  in  response  to  the 
guery  shown  in  Figure  3.139. 

KB  —  ASH  <cr> 

VR  —  "ASH  Weapons  Systems" 

This  response  will  generate  a  display  on  the  graphics 
monitor  which  shows  the  battle  group  units  in  their  relative 
positions,  and  identified  by  name.  There  are  three  capa¬ 
bilities  addressed  in  the  ASH  display,  helicopter 
(LAHPS/BS)  ,  AS RO C/S U EEOC,  and  torpedo.  Each  ship  will  have 
around  it  a  circle  representative  of  her  respective 


i  < 


I  A 


a  < 


a 
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capability.  The  helicopter  ranges  are  shown  in  "green," 
the  A SHOC/S OBBOC  ranges  in  "yellow,"  and  the  torpedc  ranges 
in  "cyan."  The  information  displayed  in  Table  XIII  shows 
the  systea  ranges  associated  with  these  systeas. 


r  ,L  n  ™ 

1  TABLE  XIII 

- 

DSS  ASW  System  Ranges 

System 

Range  (nm) 

Helicopter  (LAMPS/HS) 

100.0 

ASROC 

4.8 

SUBROC 

25.0 

EK46  Torpedo 

2.0 

MK48  Torpedo 

10.0 

......  i 

Additionally,  on  the  terminal  screen  the  unit  names,  and 
their  associated  helicopter,  ASW-Rocket,  and  torpedo  capa¬ 
bilities  are  presented.  The  format  for  this  display  is 
show  in  figure  3.144. 


♦  BATTLE  GROUP  ASW  WEAPONS  SYSTEMS  * 

UNIT  NAME  HEIICOPTEE  ASW-ROCKET  TORPEDO 

***  PRESS  RETURN  TO  CONTINUE  *** 


Pigmre  3.144  Battle  Group  AS!  Weapons  Capabilities. 
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The  display  would  sbcw  TBS/90  for  helicopter,  indicating 
that  there  is  an  A5N  helicopter  onboard  that  unit.  It 
would  additionally  indicate  the  type  of  ASW-Rocket 
(AS  ROC/S  UBROC)  ,  and  type  of  torpedo  which  are  onboard  the 
unit.  Following  this  display,  you  would  be  able  to  enlarge 
the  plot  and  display  the  threat  sector  and  cartesian  coordi¬ 
nate  axes,  as  well  as  experiaent  with  changing  the  position 
of  a  unit.  The  queries  and  responses  for  initiating  these 
features  are  shown  in  succeeding  sections  of  this  module. 

e.  Display  cf  Force  HABP009  Weapons  Coverages 

If  you  desired  to  display  the  coverage  area  of 
the  force  HARPOON  weapons,  then  you  would  enter  the 
following  response  tc  the  query  shown  in  Figure  3.139. 

KB  —  HA  SPOON  <cr> 

YR  —  "HARPOON  Weapons" 

As  a  result  of  this  input,  you  would  see  a  display  on  the 
graphics  acnitor  of  the  battle  group  units  in  their  relative 
positions,  and  identified  by  naae.  Surrounding  each 
HARPOCN  ship  would  be  a  circle  (radius  60.0  na). 
Additionally,  the  naaes  of  all  battle  group  units  with 
HABPOCN  would  be  presented  on  the  terminal  screen.  The 
heading  for  this  display  is  shown  in  Figure  3.145. 


♦  BATTLE  GROUP  HARPOON  UNITS  * 

<ship  naae> 

<ship  naae> 

<ship  name> 

***  PRESS  RETURN  TO  CONTINUE  ♦** 


Figure  3.145  Battle  Group  HARPOON  Units. 
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Following  the  display  of  this  information,  you 
will  be  able  to  enlarge  the  plot,  and  display  the  threat 
sector  and  cartesian  coordinate  ares,  as  well  as  experiment 
with  changing  the  pcsition  cf  a  unit.  The  guery  and 
response  sequences  for  initiating  these  features  are 
discussed  in  succeeding  sections  of  this  nodule. 

f.  Display  cf  Force  TOMAHAWK  Weapons  Coverage 

If  you  desired  to  display  the  force  TOMAHAWK 
weapons  systea  coverage  areas,  you  would  enter  the  following 
in  response  to  the  query  shown  in  Figure  3.139. 

KB  —  TOMAHAWK  <cr> 

VR  —  "T0HA8AWK  Systems" 

This  input  would  initiate  a  display  on  the  graphics  acnitor 
of  the  tattle  group  units  in  their  relative  positions,  and 
identified  by  naae.  Those  units  with  a  TOMAHAWK  capability 
would  have  around  then,  a  circle  of  radius  400.0  nautical 
ailes.  Additionally,  on  the  terminal  screen,  those  units 
would  be  listed  by  naae.  The  format  for  this  listing  is 
shown  in  Figure  3.146. 


*  BATTIZ  GROOF  TOMAHAWK  OMITS  * 

<ship  name> 

<ship  name> 

<ship  naae> 

***  PRESS  RETD  BN  TO  C0NTIM0E  *** 

Figure  3.146  Battle  Group  TOMAHAWK  Units. 

Following  this  display,  you  will  be  able  to 
enlarge  the  plot,  and  display  the  threat  sector  and 


cartesian  coordinate  axes,  as  well  as  experiment  with 
changing  the  position  of  a  unit.  The  query  and  response 
sequences  associated  with  initiating  these  features  are 
discussed  in  succeeding  sections  of  this  nodule. 

g.  Display  cf  Force  TOHAHARK  and  H ARPOON  Coverage 
Areas 

If  you  desired  to  display  the  coverage  areas  of 
BOTH  the  fcrce  TOHABAWK  and  HABPOON  weapons  systems,  then 
you  would  enter  the  fellow ing  in  response  to  the  query  shown 
in  Figure  3.139. 

KB  —  TOHHAR  <cr> 

?R  —  "Both  TOMAHAWK  and  HARPOON  Systems" 

Resulting  froa  this  entry  would  be  a  display  on  the  graphics 
■onitcr  cf  the  battle  group  units  in  their  relative  posi¬ 
tions,  and  identified  by  naae.  Surrounding  those  units 
that  are  capable,  would  be  circles  (TOMAHAWK  in 
"greenVHAREOON  in  "red")  scaled  to  the  ranges  previously 
discussed  for  these  weapons.  Following  this  display,  you 
will  be  able  to  enlarge  the  plot,  and  display  the  threat 
sector  and  cartesian  coordinate  axes,  as  well  as  experiment 
with  changing  the  position  of  a  unit.  The  query  and 
response  sequences  associated  with  initiating  these  feati- 
ures  are  discussed  in  succeeding  sections  of  this  module. 

2  •  Positioning  CAP  Stations 

As  you  saw  is  the  SENSOR  module,  with  the  stationing 
of  an  AEN  aircraft,  if  you  elect  to  display  missiles,  guns, 
cr  a  combination  of  the  two,  in  this  module  you  will  have 
the  opportunity  to  station  two  (2)  CAP  sections.  The  query 
utilized  to  invoke  this  feature  is  shown  in  Figure  3.147. 
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100  HITS  THE  CPPOBTUHITT  OF  PLACING  TWO  SECTIONS  OF 
F- 14  CAP  IH  SOPPOBT  OF  THE  EATTLE  GROUP. 

???  H0U1D  TOO  LIKE  TO  DO  THIS  ??? 

(IIS  CR  NO) 


Figure  3.147  Query  —  Stationing  of  CAP. 

The  desired  response  to  this  query  is  "YES"  or  "NO."  If 
you  desired  to  place  a  CAPSTA  in  the  systea,  and  enter 
"YES,"  you  would  next  be  asked  for  the  position  of  the 
station  for  each  section,  as  applicable.  The  fornat  of 
both  the  query  and  response  for  this  position  deteraination 
is  identical  to  that  in  the  SENSOR  module  for  the  AEW 
station.  The  foraat  for  the  query  is  shown  in  Figure 
3.148. 


FOR  CAPSTA  NUMBER  1, 

???  8HAT  IS  THE  EEARING  AND  RANGE  OF  THE  STATION 
FROM  ZZ  ??? 

(INTEB  AS  BEARING  IN  DEGREES  TRUE,  RANGE  IN  NAUTICAL 
HUES.  E.G.  BBB  ERR) 


Fignxe  3.148  Oner;  —  Deteraination  of  CAPSTA  Position. 


Notice  that  the  query  addresses  CAPSTA  number  1.  If  you 
elect  to  hare  two  CAPSTAS,  the  query  would  reflect  the 
ruaber  of  the  second  station.  If  you  desired  to  position 
CAPSTA  nr.  1  340  degrees  true,  100  nautical  ailes  from 
"ZZ,"  you  would  make  the  entry  shown  in  Figure  3.149  . 
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KG  —  340  10  0  <cr  >  ! 

YH  —  "Three"  "Four"  "Zero"  "Space"  "One"  "Zero"  | 
"Zero"  "Carriage  Beturn”  j 

_ I 


Figure  3.149  Specification  of  CAPSTA. 

If  an  error  were  to  occur  while  making  this  entry,  you  would 
he  so  advised,  and  given  the  opportunity  to  reenter  the 
correct  position.  After  the  position  of  the  first  CAP 
station  has  been  entered,  you  will  be  asked  if  you  desire  to 
employ  the  second  station.  The  format  for  this  query  is 
shown  in  Figure  3.150. 


??  WOULD  YOU  LIKE  TO  EMPLOY  THE  SECOND  CAP  STATION  ?? 
(YES  CB  NO) 


Figure  3.150  Query  —  Second  CAP  Station. 


The  desired  response  is  "YES"  or  "NO."  If  you  indicate 
that  you  want  another  CAPSTA,  and  enter  "YES,"  you  will 
sequence  through  the  position  determination  query  shewn 
above.  If  you  enter  "NO,",  you  will  cycle  to  the  next 

feature  cf  this  module. 

3 .  Enlarging  the  Size  cf  the  Weapons  Coverage  Display 

The  initial  size  of  the  graphics  plot  is  1000  nm  by 
950  nm.  In  some  cases,  this  scale  is  inadequate  to  accu¬ 
rately  view  the  coverages  of  the  displayed  weapons  system. 
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In  order  to  afford  yen  the  opportunity  to  change  this  scale, 
the  query  shown  in  Figure  3.125  is  presented.  You  will  be 
able  tc  enlarge  the  plot  up  to  five  (5)  times.  For  a 
review  of  the  pragmatics  of  responding  to  this  query,  refer 
to  the  appropriate  topic  in  the  SENSOR  SOD  OLE  OPERATIONS 
secticn. 

4.  lisnlav  Qf  Threat  Sector  and  Cartesian  Coordinate 

Sill 

Cnee  the  module  opticn  you  have  selected  has  been 
displayed,  and  you  have  adjusted  the  scale  as  required,  you 
will  be  will  be  offered  the  option  of  displaying  the  threat 
sector  and  cartesian  coordinate  grid.  The  query/response 
sequences  for  initiating  these  features  from  this  module, 
are  the  same  as  you  exercised  from  the  SENSOR  module.  The 
composition  of  these  queries  are  shown  in  Figures  3.128  and 
3.129.  Figure  3.151,  A  repeat  of  Figure  3.128,  is  shewn 
below . 

??•?  WCULD  YOU  LIRE  TO  SEE  EITHER  OF  THE  FOLLOWING  ??? 

1  —  VERTICAL  PLOT  AXES 

2  —  THREAT  SECTOR 

(ENTER  TEE  APPROPRIATE  NUMBER  OR  PRESS  "CARRIAGE  RE¬ 
TORN"  TO  CONTINOE) 

...  —  ■  . . . —  i  _  .  .  _ _ ... _ _  „.j 

Figure  3.151  Query  -  Threat  Sector/Cartesian  Grid. 

As  you  have  seen  in  the  discussion  from  SENSOR 
module  operations,  the  desired  response  to  this  query  is 
straightfoward.  Remember  also,  that  you  can  only  display 
the  Vertical  Plot  axes  once.  They  will,  in  fact,  remain  on 
the  screen  once  selected,  until  you  select  another  module 


cptica.  Should  you  indicate  display  of  the  VERTICAL  PLOT 
AXES ,  and  they  are  already  displayed,  then  you  will  see  the 
following. 

TOO  HAVE  ALREADY  DISPLATED  THE  VERTICAL  PLOT  AXES 

**»  PRESS  RETURN  TO  CONTINUE  *** 

Hhen  you  continue,  you  will  be  presented  with  the  query 
shown  in  figure  3.129,  and  essentially,  your  only  available 
options  ar9  to  display/change  the  threat  sector,  or 
continue.  Should  an  error  occur  in  making  this  response, 
the  following  will  be  presented. 

PLEASE  BEENTER  THE  COMMAND  EXACTLY  AS  SHOWN  IN  THE 
SELECTIONS  LIST. 

The  query  will  again  be  displayed  and  you  can  reenter  your 
response.  To  reiterate,  a  aore  in-depth  discussion  of 
these  features  is  conducted  in  the  appropriate  topics  of  the 
SENSCB  MODULE  OPERATIONS  section. 

5.  IlESHiSatalll  SMaaina  th§  Position  of  a  Onit 

The  final  capability  of  this  module  is  the  experi¬ 
mentation  with  changing  the  position  of  a  unit.  The  intent 
of  this  feature  is  that  the  user  can  observe  the  effects  on 
the  weapons  systems'  coverage  by  making  such  a  change.  As 
you  have  seen  in  the  SENSOR  module  discussion  of  this  capa¬ 
bility,  you  can  experiment  with  up  to  ten  (10)  units.  The 
number  of  times  you  mcve  a  unit  is  unrestricted.  With  each 
move,  you  will  be  allowed  to  make  that  new  position  perma¬ 
nent,  or  retain  the  original  position  of  the  unit  within  the 
database.  On  the  graphics  monitor,  you  will  see  the 
current  weapons  system  display  with  which  you  are  working. 
The  refreshed  display,  however,  will  show  the  unit  you 
selected  for  a  position  change  in  her  new  position,  and  a 
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reference  line  back  to  the  current  database  position  for 
that  unit.  Additionally,  on  the  terminal  screen  will  be 
displayed  the  respective  weapon  system  onboard  that  unit. 
The  query  for  initiating  this  feature  is  shown  in  Figure 
3.  152. 


???  EO  ICO  OSSIBE  TC  EXPERIMENT  WITH  THE  COVERAGES  BY 
MOVING  A  UNIT  V?? 

(YIS/NO) 

_ ; _ 


figure  3.152  Query  -  Changing  a  Unit's  Position. 


This  query  is  displayed  in  conjunction  with  the  queries  for 
threat  sector/cartesian  coordinate  grid  displays.  Each 
time  you  move  a  unit,  you  will  then  see  the  query  shown  in 
Figure  3.151  or  3.129.  The  system  will  cycle  through  these 
sequences  twice  before  you  finish  with  the  current  display 
cf  ycur  selected  weapons  system.  The  desired  response  to 
the  query  shown  in  Figure  3.152  is  the  IES/no  input  we  have 
seen  before.  If  you  enter  "YES,"  then  you  will  next  be 
queried  regarding  the  name  of  the  unit  you  desire  to  move, 
followed  by  the  new  position  of  that  unit.  The  pragmatics 
cf  the  cuery/response  sequences  associated  with  this  capa¬ 
bility  are  discussed  in  detail  under  that  appropriate  topics 
cf  the  SENSOB  nodule  Operations  section.  Should  you 
attempt  to  move  more  than  ten  (10)  units,  the  warning  shown 
below  will  be  presented. 

YOU  HAVE  ALREADY  MOVED  THE  MAXIMUM  ALLOWABLE  NUMBER  OF  10 
UNITS 
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If  year  response  to  the  query  shown  in  Figure  3. 152 
was  "io,"  one  of  two  actions  would  be  taken.  If  this  is 
the  first  presentation  of  the  query ,  you  will  be  cycled  to 
the  query  shown  in  Figure  3.151.  If  this  is  the  second 
tise  the  query  has  been  presented,  the  systea  will  determine 
that  you  are  finished  with  the  display  of  the  current  capa¬ 
bility,  and  you  will  see  the  following  displayed  on  the 
screen. 

*♦  CACTICH  ♦♦  THE  DISPLAYED  GRAPHICS  WILL  BE  ERASED  WHEN 
TOO  CCHTIHOE 

*♦*  PRESS  RET  DRW  TO  CONTIHOE  *** 

The  current  graphics  display,  with  all  of  the  features  you 
have  initiated,  will  reaain  on  the  graphics  monitor  until 
you  continue.  Once  you  continue,  you  will  be  cycled  to  the 
module  menu  shown  in  Figure  3.139.  If  you  desire  to 
display  another  weapons  system  capability,  enter  the  appro¬ 
priate  option.  If  you  desire  to  return  to  the  HAIR  module, 
enter  •’EXIT."  You  must  return  to  the  HAIR  module  in  order 
to  access  another  DSS  module. 


APE  ESDI!  4 

70IC2  RECOGHTIOV  COHHAHD  FORMATS 


This  appendix  ccntains  the  foundation  of  the  voice 
architecture  supporting  the  Decision  Support  System. 
Unique  to  the  foraat  structure  of  discrete  speech  voice 
recognition  primitives,  the  information  contained  in  Table 
HV  ccnstitutes  the  "prompts,"  voice  command  strings  (when 
different  from  the  "prompts")  and  the  "output  string"  asso¬ 
ciated  with  the  entries.  This  information  is  recorded  on 
the  tape  accompanying  this  Thesis.  i  brief  explanation  of 
the  procedures  far  creating  a  voice  tape  are  appropriate  at 
this  pcint. 

The  Treshold  Technology  T-600  equipment  utilized  for 
this  thesis  requires  three  segments  for  each  anticipated 
voice  command.  The  details  of  "training"  the  machine  fcr 
youp  voice  can  be  obtained  from  the  Han-Machine  Interface 
laboratory,  at  NPS.  Basically,  the  three  steps  tc  estab¬ 

lishment  of  a  voice  command  are  to  first,  determine  a 
"prompt,"  second,  input  the  "output"  string  associated  with 
that  "prcmpt"  (maximum  length  for  an  "output"  string  is  16 
characters)  ,  and  third,  "training"  the  machine  with  a  voice 
command  to  which  ycu  want  the  "output"  equated.  The 

"prompt"  and  "output"  are  referenced  by  a  three  digit  refer¬ 
ence  number  (000  -  256).  This  equipment  has  a  maximum 

capacity  for  256  commands.  Once  you  have  input  the 
"prompt"  and  "output,"  the  "training"  consists  of  speaking 
the  phrase  you  desire  so  that  the  equipment  can  establish  a 
reference  fcr  that  particular  voice  pattern.  Once  this 

"training"  has  been  completed,  the  machine  will  cause  the 
appropriate  "output"  to  be  generated  each  time  that  command 
is  made.  Once  you  have  completed  the  sequencing  of  command 
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establishment,  yoar  complete  command  vocabulary  can  be 
recorded  on  tape.  Each  subsequent  time  you  desire  to 
utilize  the  voice  commands,  you  can  load  your  voice  command 
patterns  into  the  T-6C0,  and  it  can  then  act  as  a  keyboard 
for  entry  cf  your  responses.  This  overly  simplifies  the 
mechanics  cf  creating  the  voice  commands,  however,  the 
intent  was  to  give  you  a  general  feel  for  the  process. 

A  primary  function  of  this  appendix  is  to  serve  as  a 
reference  from  which  the  acceptable  voice  commands  for  the 
system  can  be  obtained.  If  there  is  no  voice  command 
string  indicated,  the  "prompt"  serves  as  the  command  string. 
With  respect  to  the  listings  for  the  ships,  by  inclusion 
herein,  the  ship  is  verified  to  be  residing  in  the  Master 
Database  for  the  Decision  Support  System. 
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